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1. INTRODUCTION 


The Central Data Processing System (CDPS) is the Central Integration 
Facility which transforms the raw data collected at remote sites into 
performance evaluation information for assessing the performance of 
solar heating and cooling systems. 

This CDPS Software Performance Specification (CSPS) provides the medium 
for baselining the overall software system requirements. After baselining, 
the software requirements will be placed under change configuration control 
and can be changed only through formal change procedures established by 
the Marshall Space Flight Center (MSFC) . Through this procedure, the 
document will remain current with the requirements/capabilities of the 
CDPS software throughout the contractual period. 

The objective of this document is to establish the requirements which 
must be satisfied by the CDPS software. All descriptions of and references 
to the CDPS hardware configuration are only to facilitate explanation of 
the software requirements and not to control the configuration of the 
hardware. The CDPS hardware is controlled by IBM and is used for support 
of multiple contract programs. To support this varying utilization 
environment, IBM must maintain the flexibility to modify the configuration 
as required. Because of this flexibility requirement, the CDPS hardware 
configuration may vary during the performance of the SIMS contract, but 
the capability to satisfy all SIMS processing requirements contained 
within the CDPS Hardware Performance Specification will be maintained. 

This document will not be updated to reflect changes in the detailed 
CDPS hardware configuration which do not affect CDPS software requirements. 

The programming standards to be used in development, documentation and 
maintenance of the software are discussed in Appendix A. In addition, 
the CDPS operations approach in support of dally data collection and 
processing is discussed in Appendix B. 


1.1 CDPS ROLE IX SOLAR HEATING AND COOLING PROGRAM 


The CDPS, located at IBM's FSD facility in Huntsville, Alabama, 
provides the resources required to assess the performance of solar 
heating and cooling systems installed at 50 remote sites. These 
remote sites consist of residential, commercial, government, and 
educational types of buildings, and the so^ar heating and cooling 
systems can be hot-vater, space heating, cooling, and combinations 
thereof. The instrumentation data associated with these systems * 
vary according to the application and must be collected, processc 
and presented in a form which supports continuity of performance 
evaluation across all applications. In addition, data must be 
maintained for historical purposes and for detailed analysis. 

In supporting the overall program objectives, the CDPS satisfies the 
following functional requirements; 

Data Collection - The CDPS daily collects instrumentation data 
from all remote sites via standard voice-grade 1200 Baud telephone 
lines. In addition, non- instrumentation data available from MSFC, 
ERDA, HUD, etc., which is needed in performing overall system 
evaluation, is collected via manual means. 

Data Processing - The CDPS accepts raw data, as collected by the 
data collection function, and performs the data processing 
functions required to transform the raw data into processed 
information for use in system evaluaticn/analysis activities. The 
CDPS also provides the resources to maintain a performance 
evaluation data base, containing both raw data and processed 
information, for use in support of performance analysts. 

Data Archiving - To provide capability for detailed analyses of 
system performance and to maintain data for historical purposes, 
the CDPS provides the capabilities to archive data collected and 
processed during the program. Both raw data and processed data is 
retained on magnetic tape, and formal reports are archived in a 
library. 

Data Di s tribution - In addition to collection, processing, and 
archiving of data, the CDPS provides the essential function of 
distributing the data to the appropriate organizations. 
Distribution is in the fora of printed reports, data plots, and 
magnetic tapes. 

Systems Analysis Simulation - An essential capability in 
assessing the performance of solar heating and cooling systems Is 
the ability to predict performance for correlation with 
operation.: 1 performance. The CDPS provides the resources needed 
in support of :hi3 simulation activity and provides capabilities 
for automated correlation of predicted and actual performance. 
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As shown in Figure 1, Che CDPS consists of three major elements - 
communication interface computer, central data processing computer, 
and performance evaluation data base. These three elements provide 
the capabilities required to satisfy the functions mentioned above. 
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Figure 1. Role of Central Date Processing System 








1.2 CDPS FUNCTIONAL REQUIREMENTS 


In performing ics role within the eoler heating end cooling 
deaonatretion program, the COPS, through ita hardwere/software, shall 
satisfy overall system requirements. A summary of these system 
requirements is given in the following paragraphs: 

Crowth Potential - Because of the distinct possibility of growth 
in the data collection and processing requirements as additional 
sites are added to the program, the CDPS shall be designed to allow 
growth in capability with a minimum of cost. 

Data Collection - To support timely processing/presentation of 
data in support of the performance evaluation activities, dally 
collection of data shall be provided from all remote sites. 

Timely Processing of Data - The processing data flow within the 
CDPS shall minlmiza the delay between receipt of data at the CDPS 
and availability of processed information. An operations goal 
will be to provide processed information and reports at the start 
of first shift each day. 


Operations Personnel - The design goal of the system shall be to 
minimize operations personnel utilization during data collactlon 
and processing. Software shall provide built-in error 
detection/recovery techniques to allow maximum of automatic 
control. 


SDAS/CDPS Communication - Because of the availability of 
software/proven concepts on other programs which use telephone 
lines for automatic data collection, maximum benefit of this prior 
experience shall be utilized to reduce program risk. 

S ystem Recovery - The overall data collection concept shall provide 
the flexibility to ensure that site data la nut loat through 
failure of the communication interface or host computer. Backup 
shall be provided to restore entire contents of performance 
evaluation data base in the event of computer malfunction. 


Data Archiving - Within any demonstration program, availability of 
historical data must be provided in order to support the 
performance evaluation activities. The CDPS shall support this 
archiving of data and provide the means of identifying the 
location for timely retrieval. 

User Support - Because of the requirements generated through a 
diverse user community, the CDPS shall provide a flexible user 
support capability which can be easily structured to satisfy 

needs. 
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Flexibility - Because variations in instrumentation at remote 
sites, the COPS shall support the processing of variable input 
formats. 


A-6 


ORIGINAL PAGET® 
OF POOR QUAUTV 




yj 


1.3 CDPS HARDWARE DESCRIPTION 

As shown in Figure 1, the CDPS hardware consists of s communication 
interface computer configuration and a host computer configuration. 

The following paragraphs briefly describe the components of each of 
these configurations. 

1.3.1 Communication Interface Configuration • 

The communications Interface configuration provides the capability to 
collect data from remote sites via 1200 baud voice-grade telephone 
lines. WATS lines will be used for this communication and will be 
supplied by the Government. In addition, the communications facility 
at MSFC will provide the necessary communications hardware to support 
the data collection functions. Automatic dial-up and command 
Interface with the remote sites will be provided by the communications 
Interface computer. 

The communication Interface configuration operates in a standalone mode of 
operation and consists of: 

(1) An IBM System/7 computer with Input/output peripherals to 
support operator Interface, report generation, and data 
storage. 

(2) Communication Interface hardware for coomunlca cions with 
remote sites via telephone lines. 

(3) Hardware to support collection of data via manual means. 

(4) Communication hardware for transfer of data to the host 
computer configuration (IBM S/370-145). 

The overall hardware elements are shown in Figure 2 and are discussed 
in the following paragraphs. 

1.3. 1.1 System/7 Computer 

e 

As can be seen in Figure 2, the System/7 computer configuration 
consists of the following hardware: 

(1) Central Processing Unit (CPU) 

(2) Memory 

(3) Teletype Keybosrd/Prlnter (5028) 

(4) Disk Storsgs (5022) 

(5) Printer (7431) 

A-7 






yj 



Figure 2. Communication Interface Configuration 
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These hardware, with capabilities relative to CDPS objectives, are 
discussed below: 

Central Processing Unit (CPU) - The Central Processing Unit 
supports an interrupt-driven, multi-program environment through a 
priority interrupt systea. A total of 4 interrupt levels with 16 
sublevels are provided. Seven index registers, an accumulator 
register, and an instruction address register are supported for 
each interrupt level. The CPU also provides 2 Interval timers for 
timekeeping and program control. Addressing capability for up to 
64K - 16 bit words is supported. 

Memory - 24K. Words of 16 Bits Each - Main storage provides the 
communication processor with fast access, adequate storage to 
provide the control. Interface and application programs necessary 
for control of the communications Interface. The main storage can 
be expanded to 64K words through field modification. 

Teletype Keyboard/Printer - The Teletype Keyboard/Printer provides 
the operator interface required during program load, initiation of 
data collection and SDAS troubleshooting. In addition, the 
printer provides hard copy reports in support of communication 
logging, memory dumps for software debug, and maintains status of 
software operation. 

Disk Storage - The baseline configuration contains one disk unit 
which provides storage for a maximum of 2.457 million 16-bit 
words. The unit supports mountable disk files to allow storage of 
data in excess of 2.457 million words. 

Printer - The printer provides the capability for generation of 
communication and error reports during data collection. The 
printer has the capability to print 115 characters per second. 

1.3. 1.2 'Communication Interface Hardware 

The communication Interface hardware provides the interface 
capabilities which allow the System/7 computer, under software 
control, to automatically collect data from remote sites via telephone 
lines. This hardware, shown in Figure 2, consists of: 

(1) Teleprocessing Multiplexer Module (TP>M) 

(2) Auto-Call Unit 

(3) Modem 

(4) Coupler 

The following paragraphs briefly describe these hardware elements: 
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Teleprocessing Multiplexer Module (T ?MM) - The TP>M provides the 
communication interface logic for controlling up to eight 
asynchronous communication lines simultaneously. The T?MM also 
provides the interface to the System/ 7 for control of the 
communications with remote sites. 

Auto-Call Unit - The Autocall Unit consists of a Western Electric 
801 Autocall Unit and provides the interface with the TPMM for 
dial-up information and status. The Autocall Unit is an output- 
only device and performs automatic dialing of the remote sites as 
commanded by the Systen/7 via the TPMM. 

Modem - The modem is a Western Electric 202C device which is 
compatible with the modem in the SDAS unit at the remote sites. 
The modem performs modulation/demodulation of signals being 
transmitted to/froa the remote site. 



Coupler - The coupler is a standard Western Electric device which 
provides voltage transient protection for the telephone lines. 

1.3. 1.3 Manual Data Collection (Cassette Read) 


To support collection of data via manual means from remote sites, the 
communication Interface configuration contains a prototype Site Data 
Acquisition Subsystem (SDAS). Cassette tapes manually retrieved from 
sites will be Inserted into the prototype unit and transmitted to the 
Systen/7 via local telephone lines. 


1.3. 1.4 System/7 - Host Computer Communication (S3CA) 

The Sensor Based Communication Adapter (SBCA) provides the capability 
for high-speed data transfer between the System/ 7 and the host 
computer. The SBCA will transfer data at a rate of 2.2 megabits per 
second. 


1.3.2 Host Computer Configuration 

The host computer configuration receives raw data collected from all 
remote sites, on a daily basis, via the communication hardware from 
the communication interface configuration. This data is then 
processed and stored into the performance evaluation data bank for usa 
in evaluation activities. The host computer configuration consists of 
an IBM System/370-143 which is shared with ether users. Tha 
configuration is shown in Figure 3, and significant alemtnts ara 
discussed in the following paragraphs. Detailed descriptions ara 
availabla in existing IBM equipment reference manuals. 

1.3. 2.1 Sensor Based Control Unit (S3CU) 
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Figure 3. System/370 Model 145 Configuration 
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The SBCU provides che comnunicatlons medium for receipt of date from 
the communication Interface configuration for processing. Data 
transfer rate Is 2.2 megabits per second. 

I n / 

1.3. 2. 2 Terminal Support 

IBM 3277 terminal units are provided for access/update of the 
performance evaluation data base. Two terminals will be dedicated to 
the solar energy applications to ensure availability. Tabular output 
can be displayed on these terminals. 


A Tektronix 4013/4631 display hard copy unit provides the capability 
to generate either text or graphical data representative. This unit 
Is dedicated to support of the analytical/reporting requirements of 
the program. 

o.. r 

1.3. 2. 3 Magnetic Tape Units 

The configuration provides both 9-track and 7-track magnetic tape 
handling capabilities. Density for 9-track tapes is 1600 BP 1 oft 800 
BPI; whereas, 7-track tapes are 600 BPI. The magnetic tape units will 
be used to generate deliverable tapes to MSFC for use in updating the 
MSFC solar energy data base and to other data users as required. In 
addition, archival data will be placed on magnetic tape for storage.- 

1.3. 2. 4 Disk Storage Units 

The configuration provides I3M 3333/3330 disk units for use in 
supporting the performance evaluation data base. The present 
configuration contains storage capacity of 400 megabytes; however, the 
system supports expansion without hardware modification to 2 billion 
bytes of storage. One disk unit, which provides storage for 200 
megabytes, will be dedicated tovCDPS functions. 

StfhS 

1.3. 2. 3 High-Speed Printers 


Three high-speed Printers (1100 lines per minute) are provided for 
support of report generation/distribution requirements. In addition, 
reports created during processing of data will be printed for 
analysis. 


1.3. 2. 6 Console 

} 

The operation console provides the operator with visibility into and 
control of operations within the computer. It will be used to allow 
the operator to initiate daily processing of data from remote sites. 
Status during processing and operator actions required will be 
presented on the console. 


1.3.2. 7 Mainframe 


The Mainframe of Che host computer consists of a memory capacity of 1 
million bytes, input/output channels* and the Central Processing Unit 
(CPU). Memory utilization of approx 'nutely 256K bytes is anticipated 
in support of data processing func» ion s; thus, significant margin 
(excess capacity) exists. The CPU provides the Instruction set, 
memory addressing logic, registers, _nd input/output control functions 
required in support of software execution. 

1.3.2. 8 Operating System 

The System/370 operating system (OS/MVT) is utilized to control the 
execution of data processing functions within the software. In 
addition, the operating system provides the language processors 
(compiler/ linkage editors/etc.) used in generation of both the S/370 
and System/ 7 software. 

A, processing priority system is utilized by the operating system to 
maximize computer utilization. To ensure that solar energy data is 
processed within specific time constraints, a high priority level wi,ll 
be assigned. 
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1.4 CDPS OVERALL SOFTWARE DESCRIPTION 


Within the CDPS, the major software tasks to be performed are: 

o Communication Interface - for data collection 

o Input Processing - for conversion of raw data Into 
Information 

o File Maintenance - for updatlng/maintalnlng performance 
evaluation data base 

o User Support - for generation of outputs to satisfy the needs 
of the data user community. 

As can be seen In Figure 4, the major software tasks have been 
allocated to CDPS hardware configurations. This allocation is based 
on the philosophy of the Systen/7 computer configuration's performing 
the data collection function and the host computer configuration's 
performing detailed data editing, data conversion, file maintenance, 
and user support functions. 

Also shown In Figure 4 Is the performance evaluation data base. This 
data base will contain all data required to support the performance 
analyst and will reside on disk storage and magnetic tapes within the 
host computer configuration. 

Subsequent sections of this document define the detailed requirements 
which must be satisfied within the software elements and the data 
base. 
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2.0 COMMUNICATION’S INTERFACE SOFTWARE REQUIREMENTS 


The comnunications interface software will reside in a System/7 
computer and provide the communications interface functions for the 
central data processing system. 

The System/7 communications Interface software will sequentially dial 
sites over switched asynchronous telephone lines and collect sensor 
data. A site directory on disk will be used to control the proper 
sequencing of site data collection. After data collection is complete 
the System/7 - host computer link will be used to transmit the data to 
the host for subsequent detailed processing and data base update. 


2.1 FUNCTIONAL SOFTWARE REQUIREMENTS 


The communications interface software must provide communications with 
each SDAS, control the collection of SDAS sensor data, and send the 
data to the host computer. In order to meet these requirements, the 
following functional capabilities will be provided. 

o Access to Remote Sites via automatic telephone calling 
sequences contained within a site directory. 

o Control of communications signals to support a switched 
telephone Interface to each SDAS. 

o Control of each SDAS over telephone lines for data 
collection. 

o Temporary buffering and disk storage of the data from each 
SDAS. 


o Transmission of SDAS data to the host computer. 

o Manual control of SDAS commands for troubleshooting. 

The detailed software requirements associated with each of the above 
functions are presented in the following paragraphs: 
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2.2 SITE DIRECTORY REQUIREMENTS 


A site directory containing information on each site shall be provided 
for the communications Interface software to control the data 
collection process. This information shall be maintained on the 
System/7 disk to insure data integrity during power off conditions. 

2.2.1 Site Directory Information 

Information in the site directory is required for each site. The 
information shall be organized on disk by site records and fields of 
data. Each site shall have a record of information that contains 
fixed data fields. Each field of SDAS Information required will be 
described in the following paragraphs: 

2. 2. 1.1 SDAS Station Address 

This field shall contain the unique station address associated with 
each site. This field will be used to obtain the station address for 
SDAS command messages described in Section 2.4.1. 

2. 2. 1.2 SDAS Status 

This field shall provide the operational status of each SDAS. It 
shall be modified by the communications Interface software as each 
site is called, commands sent to the SDAS, and data collected. The 
Status field will allow proper sequencing during a restart of the data 
collection process. 

2. 2. 1.3 SDAS Dial Digits 

This field shall contain the autocall dial digits required to 
automatically call a site over switched lines. These digits shall be 
entered by an operator when the remote site becomes operational and 
shall remain fixed thereafter. 

2. 2.1.4 SDAS Process Requirements 

This field shall specify how often data will be collected from a site. 
It will contain the nunber of days desired between data collections. 

A "1" in this field for instance would indicate dally collection. 

This field shall initially be input by an operator when the site 
becomes operational and shall be changed only if collection 
requirements change. 

2. 2. 1.5 SDAS Data Collection Time 

This field shall be required by the communication Interface software 
to determine when data is to be collected from a site. It shall 
contain the time (year, day, hour, min, sec) that data was last 
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collected. By subtracting this field from ths current time end 
compering the result with the SDAS process requirements field, Che 
software shell automatically determine when to collect data from a 
alts. 

2. 2. 1.6 SDAS Error Information 

This field shall contain error information received from a site during 
data collection. Error information is contained in the reply message 
from a site and is described in Section 2. 4. 2. 2. 

2.2.1. 7 Number of Site Disk Extents 

Data collected from each remote site shall be temporarily stored on 
disk until forwarded to the host computer for processing. To provide 
the flexibility to continue the collection from sites when either the 
data transfer link (SBCA) or the host computer is not functioning, the 
software shall allow provisions for up to five daily collections 
before data transfer to the host must be accomplished. This field of 
ths site directory shall indicate the number of times data has been 
collected since last transfer to the host computer. Upon completion 
of data transfer, this field shall be reset to indicate that no data 
Is being retained on the disk. 


2. 2. 1.8 Site Record Index 

This field shall Indicate where the data collected from a site Is 
stored on disk. This field shall have the capability to contain five 
entries due to the collection requirement specified in 2.2.1. 7. 

2. 2. 1.9 Site Byte Count 


This field shall Indicate how many bytes of data were collected and, 
when used with the field specified in 2. 2. 1.8, will indicate where 
data was stored on disk and how much data was stored. This field will 
hold up to five entries (one for each possible data collection) . 


2.2.1.10 Initial Real Time Clock Reading / N 

f cocai TiMt) 

This field Is required In order to determine the actual (CSS) time of 
sensor readings In the collected data. It shall contain the time 
(year, day, hour, min, sec) in CST that the Real Tima Clock In each 
SDAS read zero. This field shall hold five entries (one for each 
possible data collection). 


2.2.1.11 BCH Errors 


This field shall Indicate the number of BCH errors detected during 
each decs collection (five entries shall ba provided). BCH error 
processing Is discussed In Section *.1.2 of this document. 


2.2.2 Site Directory Update Requirements 


The ability to manually update the site directory from the Systea/7 
teletype shall be provided. The fields which shall be updated are: 

o SDAS Dial Digits 

o SDAS Process Requirecents 

All other fields shall be updated under program control during data 
collection and subsequent transmission to the host. 

2.2.3 Site Directory Print Retirements 

All the site directory fields described in section 2.2.1 shall be 
printed, either upon request or when the site directory is initially 
generated. This function will not be done on-line during data 
collection but shall be initiated as an off line program. 


2.3 COMMUNICATIONS HARDWARE INTERFACE REQUIREMENTS 

In order to eutonatlcelly collect data from remote sites, software 
shall be provided to communicate with each SDAS via the communications 
hardware. Figure 5 shows the communications hardware with which the 
software shall interface. The software shall Initiate commands to the 
Teleprocessing Multiplexer Module (TPMM) to establish proper 
communications to the autocall unit and modem for both transmission to 
and receipt of data from the SDAS. In addition, the software shall 
perform status checking after every input/output operation to ensure 
correct operation. The following paragraphs define the detailed 
requirements to be satisfied in interfacing with the communication 
hardware . 

2.3.1 Interface Command Requirements 

Interface commands and required software action to initiate 
communication operations are shown in Table 2-1. 


Table 2-1. Interface Commands /Software Required Actions 


COMMAND 

SOFTWARE ACTION 

OPEN A LINE 

Initialize a communications line for asynchro- 
nous send/receive operations or a dial operation 

CLOSE A LINE 

Place a communications line in the inactive 
state. 

DIAL A REMOTE 
SITE 

Automatically issue dial digits to the Bell 801 
autocall unit and complete a connection to a 
site over a switched telephone line. 

ISSUE SDAS COMMAND 

Transmit data (SDAS commands) over an asynchro- 
nous communications line and then receive data 
(SDAS reply) over the same asynchronous communi- 
cations line. 
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Figure 5. Communication Interface Hardware 
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2.3.2 Data Integrity Requirements 

A validity check shall be required on all data sent or received over 
the communication system. This validity check will be sent/received 
every eight bytes as part of the data and will provide a data 
integrity check down to eight bytes. 

The method of validity checking shall be a cyclic redundancy code 
method called Base-Chaudhuri-Hocquenghea (3CH) . A BCH shall be 
calculated and sent with all data transmitted to a SDAS. The SDAS 
will calculate a BCH for the data received and verify the 3CH sent is 
the same value. If the value is not the sane, an error reply message 
(as defined in Section 2.4.2) shall be sent to the System/7. A 
similar verification shall take place in the communications interface 
software in the System/7 for all data received from the SDAS. Action 
taken by the System/7 software for error conditions is discussed in 
Section 2.4.2. place in the communications interface software in the 
System/7 for all data received from the SDAS. 

2.3.3 Communications Hardware Status Requirements 

During each interface command specified in Section 2.3.1, status 
checking shall be performed and status information made available 
after the operation. The types of errors required to be detected and 
required software actions are defined in Table 2-2. 




t . 
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Table 2-2. Communication Error Detection/Sof tware Action 


ERROR STATUS 

SOFTWARE ACTION 

Data Set Check 

0 Loss of Data Sec Ready 
during a read 
o Loss of Carrier Detect 
during a read 
o Loss of Clear to Send 
during a write 
o ACU not ready during a 
dial 

Make three attempts to reestablish 
communications and retry the com- 
mand. If unsuccessful, continue 
to next site* 

Data Overrun 
0 Character Interrupt 

occurred before previous 
character serviced 

Retry command three times, then 
continue to next site* 

System/ 7 XIO Error 

Retry command three times, then 
continue to next site* 

Time Out Between Characters 

Make three attempts to reestablish 
communications and retry the com- 
mand. If unsuccessful, continue 
to next site* 

Time Out - No SDAS Reply 

Make three attempts to reestablish 
communications and retry the com- 
mand. If unsuccessful, continue 
to next site* 

BCH Error In Received Data 
1 error for all consands 
Other than "Read Tape." 

10 errors for "Read Tape." 

Retry command three tines then 
reestablish communications and re- 
try three times then continue to 
next site* 

Software Error 

Stop** 

*If retrys are unsuccessfully attempted on two consecutive sites, the error 
will be considered a hard failure and processing will stop. Operator will 
notify communications personnel for trouble shooting. 

^System recovery shall be under operator control (reload of system and 
restart/contact System/7 programmer) 
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2.4 SYSTEM/ 7 - SDAS COMMUNICATIONS REQUIREMENTS 


The System/7 communications software shall initiate all communications 
with a site. Each site communications shall be Initiated with a 
command message from the System/7 and be followed by a reply message 
from the site. Figure 6 illustrates the communications command/reply 
sequences necessary to collect sensor data from a site. The following 
paragraphs describe the System/ 7 - SDAS communications requirements. 

2.4.1 Command Message Processing 

Upon establishing communications with a remote SDAS via the 
communications hardware (described in paragraph 2.3), the 
communications software shall transmit a command message to the SDAS. 
Each command message shall contain: 

1. A unique command code for the SDAS function to be performed. 

2. SDAS identification information 

3. BCH code for data validity checking 

The format of the command message is discussed in paragraph 2.4.4. 
After transmission of the command, the software shall delay for 21 
seconds awaiting a reply message from the SDAS. If no reply is 
received within the time limit, the communications software shall 
disconnect from the telephone line, print a message indicating failure 
to respond, and attempt to reestablish the command Interface. The 
software shall attempt to establish communications three times. If 
not successful, a message shall be printed indicating unsuccessful 
communications, and the software must proceed to the next remote site. 

2.4.2 Reply Messages Processing 

A reply message shall be sent to the Systen/7 from the SDAS after each 
successfully received connanrl message. Reply messages will vary in 
length depending on the command which was transmitted to the SDAS; 
however, each reply message will contain the following information: 

1. Command Code (as received by SDAS) 

2. Site Identification (as received by SDAS) 

3. Status of the SDAS 

4. BCH Code generated by SDAS for data validity checking. 

Format of the Reply Message is discussed in Paragraph 2.4.5. 

Two types of Reply Messages shall be received from the SDAS: 

Normal Reply Message - Bit 0 of the SDAS status code contains a 

" 0 ". 
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DIAL 


SYSTEM/7 


ANSWER 


RE AO CONFIGURATION AND END OF FILE COMMAND 


READ CONFIGURATION AND END OF FILE REPLY 


REWIND COMMAND 


REWIND REPLY 


READ TAPE COMMAND 


READ TAPE REPLY 


REWIND COMMAND 


REWIND REPLY 


DISCONNECT COMMAND 


DISCONNECT REPLY 


SDAS 

END OF FILE 
WRITTEN TO TAPE 
CASSETTE 


TAPE CASSETTE REWIND 


TAPE CASSETTE 
PLAYBACK 


TAPE CASSETTE REWIND 


DISCONNECT 


Figure 6. Command/Reply Sequence 
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Error Reolv Message - Bit 0 of Che SDAS status code contains a 

irpr 


Upon receipt of a Reply Message, the software shall determine the type 
of reply and perform the processing functions required for the type. 
These processing requirements are discussed in the following 
paragraphs. 

2. 4. 2.1 Normal Reply Processing 

The software shall examine the status and ECH codes returned with the 
reply message. If the 3CH returned with the data does not agree with 
the BCH calculated for the data, the software shall repeat the command 
sequence up to three times. If the reply data is incorrect for three 
consecutive attempts, a message shall be printed, communications shall 
be reestablished and three mors attempts made. If still unsuccessful, 
the software shall proceed to the next site for continuation of data 
collection. 

If the status returned indicates an SDAS error, the message reply is 
considered an error reply message and the actions specified in section 

2. 4. 2. 2 shall be performed. 

For normal reply messages which pass 3CH and Status tests, the 
software shall proceed to the next command in the site data collection 
sequence. 


2. 4. 2. 2. Error Reply Message Processing 

The error reply message shall contain status codes indicating the 
error which exists within the SDAS. These errors, with the 
corresponding required software action, are shown in Table 2-3. 
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Table 2-3. SDAS Error Conditions and Software Action 


Error Condition 

Software Action 

1. BCH Error in Previous 

Reissues command to SDAS (3 times, if 

Command 

required) then continues to next site 

2. Invalid Command Received 

Reissues command to SDAS (3 times, if 


required) then continues to next site 

3. Invalid Station Address 

Reissues command to SDAS (3 times, if 

Received 

required) then continues to next site. 

4. SDAS Devices Failures 

A message containing the status re- 

o MPX 1 

ceived is printed and the software 

o MPX 2 

proceeds to the next site. The SDAS 

o MPX 3 

error information is placed in the 

o AI Basic 

site directory field specified in 

o Interface Timer 0 

Section 2. 2.1. 6 

o Tape Control 


o Realtime Clock 


o Interval Timer 1 





2.4.3 Command Definitions 

The communications software shall support the commands to the SDAS as 
shown la Table 2-4. The actions taken by both the SDAS and the 
communications software in accomplishing the command function are also 
shown. 


Table 2-4. System/ 7-SDAS Commands/Software Action 


COMMAND 

SDAS ACTION 

REPLY ACTION 

Read Configuration & 
End-of-File 

End of file written to 
tape cassette and reply 
message with current 
Realtime Clock (RTC) 
reading sent to System/ 7 

System/7 computes when 
SDAS RTC was initially 
"0" and proceeds to 
next command 

l 

Rewind 

Tape cassette is re- 
wound and reply sent 
to System/ 7 

Reply message verified 
and next command 
issued 

Read Tape 

Tape cassette is placed 
in play mode and data 
on cassette sent as 
reply message 

Tape cassette data is 
read, BCH checked, & 
stored on disk 

Disconnect 

Reply message sent to 
System/ 7 and SDAS dis- 
connected from com- 
munications 

Reply message verified- 
any new comzand must 
dial to reestablish 
communications with 
SDAS 

Disconnect & Rewind 

Reply message sent to 
System/7, SDAS dis- 
connected from com- 
munications, and tape 
casette rewound 

Reply message verified- 
any new command must 
dial to reestablish 
communications with 
SDAS 

Read Configuration* 

Reply message sent to 
System/ 7 with current 
SDAS RTC reading 

Reply message verified 

Reinitialize** 

Reply message sent to 
System/ 7 and a master 
reset of SDAS hardware 
and software executed 

Reply message verified 

*This command usaful for verifying status of SDAS 
**Not used during operational data collection. 
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2.4,4 Command Message Format 
- _ •• 

All command messages shall hava cha following fornat: 

. .... i 6 bytes 


• t'V- • 


■W 


V>, Y.' 


Pad 


Sync 

Command 

SA 

BCH 


Pad 


Circuit Activation Bits - 1 byte 
SynchronlzaCion byte 
Unique command code 

Station Address - SDAS Identification Code 
Block Check Code for previous two bytes 
*H - Hexadeciaal digit - 4 bits 
2.4.5 Reply Message Format 

All reply messages with the exception of the Read Tape reply shall 
have the following format. 


Pad 

FF 

Sync 

. •. .* 

6C 

Command - 

HH* 

SA 

HH 

BCH 

HH 


-3 or 8 Bytes* 


PAD 


SYNC 


COM. 


SA 


STATUS 


1 

REC. CT. 
I 


REAL TIME CLOCK 


3CH 


PAD 


l«»kead Configuration. 
Commands Only 


Pad 

- 

FF 

Circuit Activation Byte - 1 byte 

Sync 

- 

6D 

Synchronisation Byte 

Command 

- 

HH* 

Comaand Received 

SA 

- 

HH 

SDAS Station Address 

Status 

- 

Ha “ 

SDAS Status 

Record 

Ct. 

- 

HHHH 

Unused 

Real 

Tima 

Clock 

- 

hhhhhh ’ ' 

24 Ble SDAS Real Tiae Clock Reading 
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BCH “ HH Block check clock for previous 3 or 8 

bytes depending on reply 

*H - Hexadecimal digit - 4 bits each 
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2.4.6 Retd Tap* Reply 

The Read Tape reply contain* data transaitted from the cassette tape 
in the SDAS. This reply message shall vary in length depending on the 
amount of sensor data on the tape. The format of the Read Storage 
Table reply is shown in Figure 7. 

2.4.7 Communication Report Requirements 

During the System/ 7 - SDAS communications required for 
an operational log or report shall be generated. This 
maintain a history of each site comaand/reply activity 
contain the following: 

0 Time infornatlon with each message 

o Commands sent to SDAS 

o Status information associated with each command 


data collection 
report shall 
and shall 


o Action taken after errors 


OATA 
SCAN 
(14 TO 42 


TIME 

(2 BYTES) 

OATA 
(6 0YTES) 

BLOCK 

CHECK 

<1 BYTE! 

OATA 
(8 BYTES) 

BLOCK 
CHECK 
(I BYTE) 

OATA 
(8 BYTES) 

BLOCK 

CHECK 

11 BYTE) 

r I 


BUFFER 
FORMAT 
1812 BYTES MAX) 


PAD 

SYNC 

COMMAND 

STATION 

STATUS 

RECORO 

TIME 

(1 BYTE) 

(1 BYTE) 

(1 BYTE) 

ADDRESS 
(1 BYTE) 

II BYTE) 

BYTE 
COUNT 
(2 BYTES) 

<3 BYTES) 


BLOCK DATA 
CHECKS SCAN 
(IUYTEI ^ . 


PAD 

(8 BYTESI 


block Record pad 

CHECK BLOCK (1 BY 
CHECK 

(I BYTE! obYTEI 


TAPE 

FORMAT 


BUFFER 

BUFFER 

BUFFER 

E NO OF TAPE 

DUM>NO 1 

DUW NO. 2 

DUMP NO. N 

MARKER 

1812 BYTES) 

1812 BYTES) 

(812 BYTES) 

112 BYTES) 


o 

§5 


Figure 7. Read Tape Command Reply Format 




2.5 DATA STORE REQUIREMENTS 

The communications interface software shall accept and store on disk 
all incoming SDAS sensor data. This data will be received as the 
reply to a Read Tape Cocmand and will be in the format described in 
Section 2.4.6. The data store software shall provide the following: 

o Buffers in System/7 memory to accept the data transmitted 
from the SDAS. Two separate, chained buffers will be 
required to allow one buffer to accept data while data is 
being written to the disk from the other. 

o Provide storage (non-volatile) of the data or. System/ 7 disk 

o Maintain the Site Directory fields chat provide an index to 
the data on disk. 

o Maintain the time (CST) that the data was collected 


2.6 TRANSMIT DATA TO HOST COMPUTER 


The communications interface software shall provide a host forward 
store capability. This software shall perform the following: 

o Automatically retrieve the sensor data for each site from the 
System/7 disk. 

o Build an identification/header record to be sent to the host 
with the data from each site. 

o Update the Site Directory fields on System/7 disk. 

o Transmit the header records and data from site to a data set 
on the S370-145 host computer. 

o Provide error recovery during Systea/7 - HOST data transfer. 

The required format of the header records and data to be sent to the 
host are shown in Figure 8. 



ID RECORD 



T DATA 


FILL 

(ZEROES) 


DATA RECORDS 




RECORD 1 RECORD 2 RECORD 5 

BCH - BLOCK CHECK CHARACTER 

FLAG - INDICATES WHETHER THERE WERE ERRORS IN THE PRECEDING 8 BYTES OF DATA 
DATA INFO 


BLOCK 


BLOCK 


BLOCK 


(BLOCKS ARE ALIGNED TO BEGIN ON A BYTE AFTER A FLAG BYTE) 


Fiijurc 8. System/ 7 Output Format 
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END OF SITE 


— i , . a - & 


COMMAND 

coot 

E, 1. 

SA 

SC 

"is 



(END OF SITE IS 8 BYTES LONG, AND BEGINS AFTER A FLAG BYTE) 
SA IS STATION ADDRESS / SC IS STATUS CODE 

BLOCK [ 


DLOCK 

STAMT 

COMMAND 

SCAN 






ENO OF 

MORE FF'S 

SCAN 

SCAN 

SCAN 


SCAN 

BLOCK 

UP TO 




8 BYTES Of EF le 

NEXT BCM BYTE 


(BLOCK STARTS ARE ALIGNED AFTER A FLAG BYTE, SCAN'S ARE NOT ALIGNED, END OF BLOCKS ARE 
NOT ALIGNED BUT MAY BE PADDED WITH EXTRA FF'S.) 



BLOCK START COMMAND 

j l — r — 2 4 3_— £ i 


COMMANO 



BLOCK 

COUNT 


coot 

£ °1S 

SA 

SC 

TIME 


TIME IS A COUNT IN 2 SECONDS ELAPSED SINCE CLOCK 
START TIME AT SITE. TIME AT START OF BLOCK. 



SCAN 


TIME 

SCAN DATA: LENGTH AND ARRANGEMENT 


DEPENDES ON SITE 


TIME IS LEAST SIGNIFICANT 2 BYTES OF COUNT 
IN 2 SECONDS ELAPSED SINCE CLOCK START 
TIME AT SITE. 


Figure 8. System / 7 Output Format (C v tinued) 



2.7 MANUAL SDAS CONTROL REQUIREMENTS 


Th« ability to manually select and send commands to the SDAS and 
monitor the reply shall be provided as an aid in troubleshooting SDAS 
or system anomalies. This capability shall also be used in Initially 
bringing a site on line. The commands provided as operator input from 
the System/ 7 teletype shall be as follows: 

o Reinitialize 

o Read Configuration 

o Read Configuration and End of File 

o Disconnect 

o Rewind 

o Disconnect and Rewind 
o Read Tape 

The reply from the SDAS and the communication hardware status shall be 
printed after each command. Printing of the data received from the 
"Read Tape" command (data written on cassette) shall be under control 
of the operator. 


3. INPUT PROCESSING SOFTWARE REQUIREMENTS 


The Input processing software, as shown previously in Figure 4, 
executes in the S/370-145 hcst computer configuration. The overall 
function of this software element is to transform raw input into 
processed information for input into the performance evaluation data 
base. This transformation requires that the software satisfy the 
requirements as stated in the following paragraphs. 

3.1 FUNCTIONAL REQUIREMENTS 

The input processing software, in performing its data processing role 
within the CDPS, shall perform the following: 

o Accept raw site data from the System/7. 

o Extract variables from scans and convert to engineering units. 

o Test converted variables in accordance with performance analyst 
Inputs . 

o Compute performance analyst defined variables, 
o Compute performance evaluation parameters. _ 

o Generate input for data base update, 

o Create history/archive tapes. 

o Create input summary reports and error messages. 

The detail requirements associated with above functions are described 
in the following paragraphs: 
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3.2 ACCEPT RAW DAT 


V?M TSE SYSTEM/ 7 


Software on the S/270 ;all communicate with the host forward store 
software on the Sys: 7 for the transfer of raw data. Communication 

shall be through a S-r.sor Based Control Unit (SBCU) attached to the 
S/370 to a Sensor Based Control Adapter (S5CA) attached to the 
5>.tfem/7. Raw data received from the Systea/7 shall be stored into a 
S/370 data set on disk for subsequent processing. The input format 
froji the S/7 was shown previously in Figure 8, and the fornat of the 
dita on the S/370 data set shall be identical to the input. Data 
Shall not be passed to subsequent processing steps if errors are 
encountered during data transmission . Data transfer shall be attempted 
five times if errors occur. If transfer is unsuccessful after five 
tries, the customer engineer shall be notified. 

Error conditions which shall be detected during the transfer are shown 
in Table 3.1. 



Table 3-1, System/7 - Host Communication Error Conditions 


Error Conditions 


Required Actions 




1. Channel Control Check 

2. Interface Control Check 

3. Chaining Check 

4. Channel Data Check 

5. Command Reject 

6. Bus Out Check 

7. Equipment Check 

8. Data Check 

9. Overrun 

10. Controller Read Timeout 


11. End of Block Response 
Timeout 

12. Incomplete Read Operation 


13. Invalid Controller Address 


14. Incomplete Sense SBCU 


15. Invalid Order Response 


16* Invalid Branch 
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1. Message issued to console. Retry of 
transmission will depend on sense 
settings associated with error. 

2. Message issued to console. Retry of 
transmission will depend on sense settings 
associated with error. 

3. Message issued to console. No retry. 

4. Message issued to console. Retry response 
on sense settings associated with error. 

5. Message issued to console. One retry per- 
formed. 

6. Message issued to console. One retry per- 
formed . 

7. Message Issued to console. Five retries 
performed. 

8. Message Issued to console. No retry per- 
formed . 

9. Message Issued to console. No retry per- 
formed. 

10. Message issued to console. One retry 
performed. 

11. Message issued to console. No retry 
performed. 

12. Message Issued to console. No retry 
performed. 

13. Message Issued to console. No retry 
performed. 

14. Message Issued to console. No retry 
performed. 

15. Message issued to console. No retry 
performed. 

16. Message Issued to console. No retry 
Performed. 
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Table 3-1. Syatem/7 - Host Communication Error Conditions (Continued) 


Error Conditions Required Actions 


17. Invalid End-of-Block Response 17. 


18. Invalid Attention Response IS. 

19. No Controller Selected 19. 

20. No Request Code 20. 

- J 

21. Order Response Timeout 21. 

22. Request Code Overflow 22. 

23. ALU Check 23. 


Message issued to console. No retry 
performed. 

Message issued to console. No retry 
performed. 

Message issued to console. No retry 
performed. 

Message issued to console. No retry 
performed. 

Message issued to console. No retry 
performed. 

Message Issued to console. No retry 
performed. 

Message issued to console. No retry 
performed. 
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3.3 DECOMMUTATE RAW DATA INTO SCANS 


1 n 1 v* • 


Decommutating raw data into scans shall include: 

o Separating BCH's and flags from the data. 

o Determining the location of Block-Starts, End-of -Blocks, 
and End-of-Sites. 

o Extracting scans from the data. 


f’-.r 


' M- T" 

i ym-' 

■ 


Computing scan times in local standard time at the site from the 
site base time and the relative time values in block-starts and 
in the time value preceding each scan. 


Error processing shall Include: 




Stopping the processing for a site if the program cannot locate 
where blocks and scans begin and end. An error message shall 
also be printed indicating that data has been rejected. 

Storing a scan into a rejected-scan data set if the time of the 
scan is uncertain because of 3CH error or the time fails time 
continuity tests. An error message shall also be printed 
indicating time of scan and reason for rejection. 
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3 . 4 EXTRACT VARIABLES CONVERT TO ENGINEERING UNITS 

A 

The input processing software shall process variable formats for data 
variables within scans. The software shall maintain a site 
description directory to provide a detailed definition of the location 
of each variable within each site's input data stream. 

To extract variables from scans, the scan file created during 
decomnutation shall be used as input. The software shall locate each 
variable requiring calibration/conversion through use of the site 
description directory. 


Variables shall be calibrated and converted to engineering units using 
performance-analyst-supplied conversion type and conversion constants 
for each variable. The following conversion types shall be provided: 


Linear: 
Quadratic: 
Third Order: 
Discrete: 


Eng-Unlts ■ A +(3 x Raw) 

Eng-Units ■ A +(3 x Raw) + (C x Raw2) 

Eng-Units * A +(3 x Raw) + (C x Raw2) + (D x Raw3) 
Eng-Units ■ 1 if A < Raw <_ B 
0 otherwise 






3.5 CONVERTED VARIABLE TESTING 

After conversion to engineering units, individual variables shall be 
tested for: 

o Exceeding liaits specified by the performance analyst 

o A change between successive readings which exceeds a maximum 
specified by the performance analyst 

o A BCH error flag for the portion of the data stream from 
which the variable was extracted. 

A variable which fails two of the above tests shall be rejected. A 
failure indication value shall replace the computed value in the 
output used to update the data bank. The rejected computed value, 
along with identifying information (site id, time, and an indication 
of which variable the data is for) shall be stored in a rejected 
variable data set and shall be included in error messages/reports to 
the analyst. 

The capability shall be provided to perform tests for no change in a 
variable. This capability shall be selectable via performance analyst 
input. Variables failing this test shall be included in error 
messages provided to the analyst. 

Control over the level of detail of error messages shall be provided 
to the analyst. Capability shall provide detail messages (to the 
variable level), summary messages, or no messages. 


3.6 COMPUTE PERFORMANCE ANALYST DEFINED VARIABLES 


To provide che analyse with flexibility in analytical evaluation of 
site system performance, the input processing software shall provide 
the capability to compute new variables which are functions of input 
variables within the data stream. These variables shall be computed 
based on input provided by the analyst. Capability to combine up to 
four input variables mathematically (add, subtract, multiply, or 
divide) and to multiply the resultant value by a coefficient shall be 
provided within the software. The software shall be designed to accom- 
modate additional mathematical functions (as required by the analyst). 

If any variable specified to be used in a performance analyst defined 
variable has been rejected during testing, the performance analyst 
defined variable shall not be computed. The output shall be set to 
-99999 to indicate that computation was not performed. 

Performance analyst defined variables shall be computed on a detailed 
level (Scan) . These variables shall be Included in data base update 
information. 
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3./ COMPLTf ?C 70RMANCE EVALUATION’ PARAMETERS 


Since a stan4ar< sec of solar heating and cooling system performance 
evaluation criteria will be used, the input processing software shall 
utilize the J[i± instrumentation data and manually provided data to 
compute these evaluation criteria. Instrumentation input to these 
computation* shall consist of input variables after conversion to 
engineering units and testing functions have been performed. 

Variables at the scan level shall be utilized in conputations. Manual 
input of parameters such as system type, collector area and hot water 
temperature required in computation of performance parameters, shall 
be provided by the performance analyst. Resulting performance 
parameters shall be Included as output for entry into the data base. 

The following performance evaluation parameters shall be computed: 

o Solar energy provided for hot water 

o Auxiliary energy required for hot water 

o Solar energy provided for space heating 

o Auxiliary energy required for space heating 

o Solar energy provided for space cooling 

o Auxiliary energy required for space cooling 

o Hot water subsystem loss 

o Total available solar energy 

o Total collected solar energy 

o Collector array efficiency 

o Total solar energy utilized 

o Solar system conversion efficiency 

o Solar system operating energy required 

o Total auxiliary energy required 

o Percent solar applied to load 

o Conventional energy savings 

o Percent of time dwelling comfortable 
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0 


Percent of tine hot water available 


Table 3-2 contains the equations which shall be utilized In computing 
the above paraaecers. Also included in the table is the definition of 
term* and units shown in the equations. 

In the coeputatlon of the performance paraaecers, use of any 
instrumentation variable which has failed testing criteria shall 
result in the performance parameter being set to a -9999 value. 

In this manner, no invalid performance parameter shall be calculated 
and entered into the data base. 
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Table 3-2. Page 1 of 3 


1 SOLHW - FPH» DTPH* CP • FLDEMS • K1 

2 AUXHW - WHWAU 

3 SOLSH - FKC • DTHC • CP • FLDEMS ♦ K1 , if DC - 0 

0, otherwise 

4 AUXSH - WAUE , if DC - 1 

otherwise 

5 SOLSC - FKC CP FLDEMS Kl, if DC - 1 

0, otherwise 

6 AUXSC - WAUE , if DC - 1 

0 , if otherwise 

7 HWLOSS - (S0LHW+AUXKW)-(FHW.THW-TSW).CPW.DENSW«K1) 

8 SOLAVL - KT*CLAREA* K2 

9 SOLCOL - FCA.DTCA.CP. FLDEMS *K1 

10 COLEFF » SOLCOL 

SOLAVL • 100 

11 SOLUTL - SOLHW+SOLSH+SOLSC 

12 SOLEFF - SOLUTL 

SOLCOL • 100 

13 30L0P ■ WCP+KPHP+WhC? , if collector type ■ liquid 

WCF+WPHF+KHCF, if collector type - air 

14 AUXTOT - AUXKW+AUXSK+AUXSC 

15 PCSOL - SOLUTL 

(SOLUTL+AUXTCT • 10Q 

16 SOLSAV - SOLUTL 

(COMEFF/lOO) -SOLOP 

17 PCTDC -• 100, if TID & RHP within confort limits 

(72 s TID s 78, 2C s RHP s 60) 

0, if otherwise 

18 PCHWA - 100, if TKW & TEKRZQ 

0, otherwise 
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Coda 

Description 

Units 

SOLHW 

Solar energy provided for hot vater 

KW 

AUXHW 

Auxiliary energy required for hot water 

KW 

SOLSH 

Solar energy provided for space heating 

KW 

AUXSH 

Auxiliary energy required for space heating 

KW 

SOLSC 

Solar energy provided for space cooling 

KW 

AUXSC 

Auxiliary energy required for space cooling 

KW 

HWLOSS 

Hot water subsystem loss 

KW 

SOLAVL 

Total available solar energy 

KW 

SOLCOL 

Total collected solar energy 

KW 

COLEFF 

Collector array efficiency 

Percent 

SOLUTL 

Total solar energy utilized 

KW 

SOLEFF 

Solar system conversion efficiency 

Percent 

SOLO? 

Solar system operating energy required 

KW 

AUXTOT 

Total auxiliary energy required 

KW 

PCSOL 

Percent solar applied to load 

Percent 

SOLSAV 

Conventional energy savings 

KW 

PCTDC 

Percent of time dwelling comfortable 

Percent 

PCHWA 

Percent of time hot water available 

Percent 

FPH 

Preheater heat exchanger flow rate 

Gallons 

Minute in liquid system, 

Cu Ft. 

Minute in air systems 

DTPH 

Preheater input differential temperature 

*F 

CP 

Specific heat of transfer fluid 

BTU 

Pound -*F 

K1 

Conversion constant .0176 

From BTU to KW 
Minute 

WHWAU 

Domestic hot water auxiliary power 

KW 

FHC 

Load heat exchanger flow rate 

Gallons 

Minute in liquid systems 

Cu. Ft. 

Minute in air systems 

DTHC 

Load heat exchanger differential temperature 

*F 

WAUE 

Auxiliary Electric Power 

KW 

DC 

Cooling subsystem discrete 

1 ■ cooling, 0 not cooling 

FHW 

Domestic hot vater flow rate 

Gallon 

Minute 

THW 

Hot water supply temperature 

*F 

TSW 

Domestic service water temperature 

*P 

CPW 

Specific heat of water 1 

BTU 

Pound -*F 

DENSW 

Density of vater 

Pound 

Gallon 

HT 

Collector incident total solar radiation 

A-50 

BTU 

Sq. Ft. - Hour 
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Code 

Descriptions 

•Units 

CLAREA 

Collector area 

Sq. Ft. 

K2 

Conversion Constant .000293 

BTU 



Hour to KW 

FCA 

Collector array flov rate 

Gallon 



Minute in liquid systems, 



Cu Ft 



Minute in air systems 

DTCA 

Collector array different temperature 

•f 

WCP 

Collector pump pcver 

KW 

WPHP 

Preheater pump power 

KW 

WHCP 

Load heat exchanger punp pcver 

KW 

WCF 

Collector fan power 

KW 

WPHF 

Preheater fan power 

KW 

WHCF 

Load heat exchanger fan power 

KW 

CONEFF 

Conventional energy conversion efficiency 

Percent 

TID 

Dwelling Indoor dry bulb temperature 

•f 

RHP 

Dwelling indoor relative humidity 

Percent 

THWREQ 

Hot water nininum temperature required 

*F 
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3.8 GENERATE INPUT FOR DATA BASE UPDATE 


The input processing software shall generate input to be used for 
updating the data base. The input for each detailed scan shall be 
formatted as shown in Figure 9. These scans shall be blocked such 
that each input record to the file maintenance software contains six 
hours of data from the remote site. Each element of the input format 
shall contain one of the following: 

(1) A value which has passed all testing criteria 

(2) An indication that the element does not apply to the remote 
site 

(3) An indication that the value has been rejected during 
processing 

The definition of each element's contents, format, and engineering 
units is shown in Table 3-3. 

Data base update records 3hall consist of: 

(1) Detail data (scan level) 

(2) Hourly data (summarized from detail data) 

(3) Dally data (summarized from hourly data) 

The requirements associated with the generation of these data are 
discussed in the following paragraphs. 

Detail Data 


Detail records shall contain values of directly-read variables, 
performance analyst-defined computed variable?, and performance 
evaluation parameters. These data shall be at the scan level 
(baselined at 5 minutes). All variables, which either are not 
applicable to thi 3 site or have failed processing testing shall be 
flagged with appropriate indicator fill words. 

Hourly Data 

Hourly data shall be computed from the detail data described 
previously. If all values of a variable within the corresponding 
detail data (12 scans) have either failed testing criteria or are not 
applicable, the hourly value shall be set to -99999. If values exist 
which have passed tests and if the detail data is applicable to the 
•ite, the hourly computed variable shall be computed as shown in 
figure 10 and written to the data base input file. 
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Daily Data 


Daily data shall be computed from the hourly data. If all hourly 
values of a variable have been set to -99999, as described above, the 
corresponding daily variable shall be set to -99999. If hourly values 
exist which have passed testing, a daily data computed value shall be 
computed as shown in Figure 10. 

For these daily variables which are totals, a summation of hourly 
totals shall be performed. 

The data base input shall contain detail records for the past month, 
hourly records for the past month, and all daily records generated to 
date. Dally input for data base update shall contain all site 
operational records to be put into the data base not just new or 
changed records. 
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o 


"'DCfl NIPS INPUT.*"/* RECOPD FOR INPUT TO Nl^S «/ 

2 NI^S CHARCli. /* CONSTANT _?N? FOR Nl°S 

2' Slfi '10 =I'C » <39999 • ♦~/«Sl TE‘ ID 


2 SYS TX°E C H A P ( 2 ) « 
2 YEAS ° I C • ? 0 * t 

2 PAY P IC *0 c a J_, 

“2 hcur pic . 

2 MIN a IC • 99' « 

2 LEVEL CHAR C 1 > • 


2 

p$ ru 


r I XEDO 1 

.ft) 

./■ 

2 

PCPQ 

H IN 

F I X r 0 ( 3 1 

. ft ) 

. / « 

2 

PCFU 

*? IN 

F IX EDI 3 1 

, r ) 

./ * 

*5 

PHCPQ 

3 IN 

FIXED (31 

t A ) 

./« 

• 2 

phcf r 

GIN 

F I /EDI 3 1 .ft ) 

. / « 

2 

PPriPO 

MIN 

F I *EDO I 

) 

./ • 

2 

DP CP 

0 IN 

F I <ED f 3 1 

• ^ ) 

./» 

o 

w 

CPCF 

9 IN 

FIXED (3 I 

• 6 ) 

./• 

* ••2.DPHCD 

M IN 

r ixedoi 

.6) 

. /• 

2 

OP MCE 

3 IN 

FIX ED (31 

. 6 ) 

./ ■ 

2 

TDS 

0 IN 

FI X E ? ( 3 T 

.ft ) 

./« 

2 

TWO 

9 IN 

r I XED (31 

• 5 ) 

. /« 

7l 

TIO 

9 IN 

F !X = D(31 ) 

./■ 

2 

TCA I 

0 IN 

- I XED I ? 1 

. si 

./« 

2 

TCS 

0 IN 

FIXED (31 

. c ) 

,/< 

2 

TPHO 

o IN 

F I XED (.3 1 

.ft) 

./• 

2 

TST 

9 IN 

r TXED (3 1 

, ft » 

,/• 

2 

THCI 

9 IN 

f I X ED I 3 1 

. ft ) 

,/ « 

2 

TCO 

0 IN' 

F IXEDC3 1 

. ft) 

./« 

2 

TCT5 

9 IN 

FTXEDOl 

.ft) 

./ * 

2 

TSW 

ft IN 

F I XFD( 3 1 

. r ) 

./■ 

2 

THW 

0 IN 

F I XED (3 1 

,o ) 

./ - 

2 

DTPH 

3 IN 

F I XED ( 3 l 

.ft) 

./- 

2 

DTHC 

0 IN 

F I XED (31 

.ft) 

♦ /• 

f- 

CTCT 

*J IN 

FI <ED(3l 

t 6 ) 

./• 

. 2 

OTCL 

li 1*4 

FIXED! 31 

.ft) 

./« 

2 

DTCA* 

9 IN 

F IXED(3 1 

.s > 

./ ■ 

2 

FHW 

3 IN 

F I XED( 31 

.f ) 

./« 

2 

FPH 

min 

F I X E 0 ( 3 1' 

. f ) 

./• 

2 

Fhc 

1TIn 

“F I x E 0 ( 3 1 

.ft ) 

./• 

2 

FC A 

B IN 

FIXED! 31 

, i- ) 

. /* 

2 

WC° 

IN 

FIXEDOl 

«r ) 

./ * 

? 

WC.F 

ft JN 

F T XED ( 3 1 

■> ft ) 

. /• 

2 

"whw A'u ' 

3 IN 

>' lxfcD(31 

.ft ) 

,/« 

2 

wphp 

3 IN 

FI XEDO 1 

.ft) 

./• 

2 

WPI F 

9 IN 

FIXED! 31 

. ft ) 

. /- 

2 

w'<C 3 

0 I >4 

FIXEDOl 

• 6 ) 

,/ * 

. 2 

*ftfCF 

"? 

T rXEO'f 3 1 

. <.i 

./« 

2 

WAUE 

R IN- 

FIXEDOl 

.6 ) 

,/ r 

2 

WAU3 

c? IN 

FI <ED( 31 

.ft) 

./* 

2 

WAIKJ 

p in 

f ixedoi 

» ft ) 

. /■ 

d 

WC TE ° 

9 IN 

FIXED (31 

.ft ) 

»/• 


SYSTEM T Y°E 

YE A° CF THIS RECORD 

DAY CP -HlS RECORD 

HOUR 3r T H fb ^ECORD 

MINUTE OF THIS RECORD 

level: A=JETAIL. p^hOUPL y»c=da tly 

./•STQPACiE TAN< ULLAGE W.SSJUPs 

» / «C CL LEC T ps P'JVP CUTLET aa^ssupc 
./•COLLECTOR PAN OUTLET PRESSURE 
./•LOAD hZAT EXCHNGR oi J'<P CUTLET OPES 
, / «l C A 0 HE i T_ ~ XCHA NG? _F A N_ "I '_T LET PRES 
./•PREHEAT g ’■? du"«p OUTLET PRESSURE 
♦/'COLLECTOR RUMP OfFFERENTAtL PRES 

♦ /•COLLECTOR FAN OIFFF.RENT I al pressup 
./•LOAD HEAT EXCHANGER RU.ap .CJKfL PP^S 
./•LOAD HEAT EXCHANGE^ FAN DIFF PRF.S 

♦ /•OUTDOOR (AMBIENT) CRY HUL ? TEMP 

♦ /•OUTDOOR (AMBIENT) MET RUL9 TEMP 

, / " V < F LL I N 5_ I NO O CR 0 GY ~ *UL -1 TEMP 

". /■« COLLECTOR AP^i AY fNL5 T TEMP 
./ ^COLLECT JR SURFACE TEMPERATURE 
./•DOMESTIC PREHEATER CUTLET TEMP 
./•STORAGE TAN< -TEMPFPATUPE 
./•LCkC h£AT EXCHANGER INLET T?md 

./•chiller cutlet temperature 

./•'"OGLING TOMER SUPPLY TE VP£9 A TURE 
,/«OC‘-*ESTI C SERVICE '*'4TiP TEMP ERATUR E 
.'/•hCT'Ta'TES SUPPLY 'TEMPERATURE 
./•dREHEATEP INPUT DIFF TEmdqsaTIJRE 
♦/•LOAD HEAT EXCHANGER DIFF. T=m? 
./•COOLING TOMER DIFF TEMPERATURE 

♦ / « ' 5 3C-< °TN " CHlLLEP EVAPRTS DIFF TEMP 
./•COLLECTOR ARRAY JIFF T-mdeRAT UR E 

. / * 0 C *•’ E S T I C HOT WATEP FLO v RATE 
,/tDO; HE_A T E R HE A TEX CHAN GE D FL O N RA TE 
./•LOAD He At r.X CHANG PP'VLOVtf RATE 
,/*CCLLEC TOR ARRAY FLO'H PATE 
./♦COLLECTOR =U'<o POWER 

./•COLLECTOR pan POWER 

./•DOMESTIC HOT" WATER AUXILIARY POWER 
,/«d=EHEAT== DUMP LOWER 

♦ /*PR*-H“ ATF- FAN PO.VE» 

./•LOAD meat EXCHANGE'* P'JMD dhwep 
. /«LO‘VO he AT FVchX.NocCP F"an “POwrTS 
♦/'AUXILIARY ELECTRIC POWER 
♦/‘AUXILIARY GAS POWER 
./•AUXILIARY OIL- POWER „ 

./■COOLING t O/-fcR 6F.VAPR ATN PUMP PfViEP' 
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2 WRAP 
_2_HT 


2 P HP 
2 DHC 
2 DC T P 
...-2.3.C. 

2 V*\D 
2 D*Nt> 

2 SP1 
2 S^2 


2 SP3 
2 SPA 
2 S°5 
JL_SP<L_ 
2 S»7 
2 SP3 
2 SP9 
2 SPID 


2 SDLH.V 
■2 AUXHW 
2 SCL5H 
_2_ A .U.<?.H_ 
2 SCL5C 
2 AtJ <SC 
2 HWLOSS 

_JL.srLA.vu_ 

2 SCLCCl. 

2 CCLEFF 
2 SOLUTL 

2_SCLE FF 

2 SOLOP 
2 AUXTDT 
2 PCSOL 
2 S ?L S A V 


3 IN 
._?XL 
r- pi 

? IN 
•3 IN 
A IV 
' .=• I'l 
<3 IN 
3 IN 

■a T'.| 

“Tt"7 
a if. 
B IN 

JJN. 

'} I n. 
3 IN 
3 IN 
_? I N_ 
fi IN 
3 r* 
n In 
3 IN 
BI i 
3 IN 

a in 

n I >v| 


2 l?CTUC 
. _Z PC,H*A _ 


P IN 
DIN 
** I V 

P IN 
3 IN 
5 IN 
B IN 
n_IN 
t j I \ 
3 IN 


FIXED (31. ft 
FJXEOj3JLj,ft 
F I XED ( 3 1 . <S 
F l*E0(31 .6 
FIXEDC31 
F I X ED ( 3 1 
r I < ED ( 3 1 
r XXE3( 31 
FIXED! 31 

fY* CD 13 l 
F I XED (31 
r ! X EID ( 3 1 
F I XED ( 3 L 
FIX EC ( 31 
FIXED (31 
FI XED< 31 
JM X = DJ 1 J 
r I X E 0 ( 3 l" 

F IXEOI 31 
FIXEC(31 
FI XEGi 31 
F IXETO 1 
FI K5D ( 31 
F I /£ 0 ( 3 1 
FIX ED ( 3 1 


r I X ED ( 3 1 
F I X ED ( 3 1 
F I XED( 31 
£ I XED ( 3 l 
F-I X EC ( 3 1 
F IX ED (3 1 
FI X E C ( 3 l-» 
r ! x ED ( ? 1 
FIX E D ( TTl 
F I XED (31 


J. 


/•RETURN AIR FAN POWER */ 

/ * D D LL TC a T N’<LI DPZI T TOT *3 o n? R a q */ 

/•DUELLING I\OOC» RELATIVE HUMIDITY */ 
/ 0 \ 1 H£‘A T EXCHAN GEP ON/OFF 0 I SC PE T*/ 

/■CODLING T 0 '* E - pyvip GN/OFF DISCRETE*/ 

/■codling «» y 3 S y 5TE. M . D.l.3 CSE TS 

/■'I'D 5P.EE D */ 

/-'A INC DIRECTION - */ 


/ ■ S ® A .G E 
/ « •' = :. r “ 
/ * > ^ ■ 
/* ;oaoc 
/ * 5P ^Sf 

✓ « :a 4 P= 

/ * 3 p i s “ 

/«3 C A"E 

/ ■ 

/*i 315 S 
/ ■» ^ r ' L A 3 
/« VJXIL 
/ *5 CLAP 
/«A«;xlL 
/'••SCLAG 
/ • A J * I L 


1 

3 

*1 

U 

3 

•3 

7 

3 

9 

1 •; 

“energy" 

ENF RGY 
c NE c GY 

.E.NJ ,KGY. 
EUE PGY 
ENERGY 


*/ 

■/ 


•*/ 

»/ 

*/ 

•*/ 

*/ 

*/ 

■x/ 


OPOV FOR HOT VAT EP «/ 

Sr. Q FCP HOT WATER «/ 

PPGV FQP SPACE HE A TNG*/ = 
P=S FCR._E.- 3a JI2w.HE>\J_In.G*^. 
PROV rG J SPACE COOLNG«/ 


RED FOR SPACE 


COOL !NG«/ 

/*HOT WATFR sudsysten LOSS «/ 

/■TOT A l A y A Tl A •' I .E 3 ° LAR EN ERGY -/ 

/■TOTAL COLLECTED SCLAP ENERGY • */ 

/•CCLLECTOP ARP AY EFFICIENCY ■■/ i 

/■total SOLAR ENERGY utilized */ ; 

/*SOLA-»_SYST=M_ CONVERSION £FFI C.IFNQy«Zj 
/■SOLAR SYSTEM OPERATING ENERGY PEG ■/ 

/■total auxiliary required- - */ 

/•PERCENT SOLAR applied TQ LOAD «/ 

/ jh* 0 N VE NTICNAL ENER G Y S A v I NGS «/ 

/ 'PERCENT OF TIM? cTwELLNG COMFTP TA3L -/ 
/-PERCENT OF TIVE HOT <at£k AVAILA3L-/. 
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CODE 


VARiadLk wcsckihi. 




1 


Mt-WW 


5 TU 
cpn 
CFO 
;, HC3n 
PH CFG 
PHPO 

UQO 

PC F 
DPHCP- 
DPHCF. 
09 
•a 9 
I O. 

:ai 

cs 

PHQ 

sr 

hci 
co 
crs 
s- - , 

HM 
T r*H 
DTHC 

TCT 

T CE 
T C A 
HW 

oh! 

HC 

c a 
c° 

CF 
WM (KiU 
> ’HP 
WPHF 
H CP . 
HCF 
AUE 
AIJG 
WAUO 
a C TE° 
AF 

V 

HP 

hC ~ 
C” "> 

c 

V WND 
WND 
P I 
■'2 
P 3 
DA 
•’ 5 
Pf. 
p 7 
"”3 
PP 
PIC 

JLHW 
UXH’.' 
SOLSH 

AUXSH 
SOL SC 
AUX5C 
HWLOSS 
OLA VL 
OLCOL 
( OLE FF 
SOLUTL 
SOLEFF 
SOLOP 
A UXTOT 
PC SOL 
'•OLSAV 
PC TOC 
PCHWA 


j 

TOLLhC TC» P'IMP OUTi E T PRESSURE I 

CPLL'CTOP fan OJ T|_ E T PRESSURE 
LOAD HEAT -XCHNC.P P'JMD OUTLET PTvrs : 
LOAD HEAT c XCHANGP fan outlet 3KCS 

PPEHEATEP PUMP P'JTLEJ- P’ ^E SSLi PE , 

COLLECTOR PUMP 0 I ^>epFNTA t L ppfs 
COLLECT OP FJN D I T ~F PE NT ! A L P 0 ES5UO| 
.LOAD- HE A T- L X CH A ,NG = R. . PU VO. . D I FJ =— P PE S 
'LOAD HEAT EXCHANGED FAN D IFF d=ES 
OUTDOOR (AMBIENT) DRY BULP TEV° 
J0UTD30R (AMBIENT) *E T E3UL0 TEMP 

..OWrLL I NG INDOOR DRY BULB TEMP 

COLLECTOP ARRAY I NLF.T TEMP 
COLLECTOR SURFACE TEMPERATURE 
DOMESTIC DPFHEATFR OUTLET TEMP 

.3T0RAGE-TA.N< . TEMPERATURE - 

LOAD HEAT EXCHANGER INLET TEMP 
CHILLER OUTLE T TEMPERATURE 
COOLING TOWER S'J? 3 LY TEMPERATURE 
DOMESTIC SERVICE w A T ER - . T F m DENATURE 
HOT WATER SUPPLY TEMPERA Tips 
.PREHEATER INPUT D I FF tevperatuRE 
LOAD HEAT EXCHANGER DIF- TE MR 
•COOL I N'G .0 OWER DIFF. TEMPERATURE.— 

'A 9 S0° P TN CHILLFR EVAPRTR OI c F TEMP 
COL) FCTOR ARRAY D I FF TEMPERATURE ; 
DOME STIC HOT WATER F|_0w PATE I 



ESTIMATED 

AVERAGE 

PSIG 


ESTIMATED 

AVERAGE 

PS)D 


ESTIMATED 

AVERAGE 

OF 


ESTIMATED 

AVERAGE 

PSIG 


ESTIMATED 

AVERAGE 

PSID 


ESTIMATED 

AVERAGE 

•F 


DOME STIC 

preheater meat exchanger flow rat’eI 
.LOAP heat r x changer Flow rate 
•COLL aC TOR array flow rate i 

COLLECTOR PUMD o nyrp 

-COLLECTOR FAN POWER ! 

DOMESTIC HOT WATER AUXILIAPY POWER 
PREHEATER PUMP LOWER i 

PREHEATER FAN POWER 

LOAD HEAT r X CHANGER PUMP POWER i 

LOAD HEAT EXCHANGER FAN POWER 
AUXILIARY ELECTRIC ROWER 
AUXILIARY GAS power 

AUXILIARY OIL- POWER : 

iCOOlInG T.jwEPr.f- vaRRATN pijmp POWER 
RETURN A I FAN PPiV R 

COLL EC T QP INCIDENT TOT SOLAR PAD . 
DWELLING, INDOOR RELATIVE HJMIDlTy 

"load heat "e xchanger on /off* 'dTscrE t 

.COOLING TOWER pjmd qn/DFF DISCRETE 
COOLING SUBSYSTEM DISCRETE '* I 

.WIND SPEED j 

•w I NO 0 I RE r T I ON 


I GAL/MINUTE 

rt3ALT.ur.Ulb 
lUIQ SYSTEM OR 
|CU FT/MIN 


GAL/MINUTE 


9TU/tHR-SQ FT) 

PERCENT 


IESTAVG GAL/MIN 


EST AVG 
SAME AS DETAIL 


KWH 

EST OF KWH USED 
THIS HOUR. 

SAME AS EST. AVG. 
OF KW 


EST. AVG 



n -on 

)o - OFF 


SWAPr 
SPARE 
’SPARE 
:S P A R E 
SPARE 
SPARE 
GPARF 
FR ARE 
iPARC 
SPARE 
SOLAR 
AUX I L 
SOLAR 
AUX I L 
-SOL AR 

A’JXIL 


1 

2 

3 

4 

5 

6 
7 
A 
O 

1C 

t NEPG Y 
ENERGY 
ENERGY 
ENERGY 
ENFRGY 
ENCPC.Y 


}0-OFF 

1 1 -COOLING 

Imiles.hr 


UNKNOWN 


EST. AVG. 


EST. AVG. PERCENT 


EST. AVG. 


EST. AVG 


EST, AVG. MIL 


EST. AVG 


SOLAR ENERGY PR.OV FOR HOT WATER | 

AUXIL ENERGY Rp 0 FOR IPT W A T E 3 
SOLAR ENERGY RROV FOR S°ACE H£* TNG 
AUXIL ENERGY RCO FOR S^ACE 
.SOLAR ENFRGY PR OV FOR SPACE COOLNG 
A’JXIl ENCPGY REO FOR SRACE COOLING 
HOT WATER SUBSYSTEM LOSS 

TOTAL available solar energy ! 

•TOTAL. COLLECTED. -SOLAR .ENERGY : 

COLLECTOR ar=»ay EFFICIENCY 
TOTAL SOLAR ENERGY UTILIZ'D ' 

■SOLAR SYSTEM CONVERSION EFFICIENCY 
.SOLAR SYSTEM OPERATING ENERGY R F 0 .. 
iTOTAL AUXILIARY r EOU i red 
PERCENT SOLAR ALLIED TO LOAD 
.CONVENTIONAL ENERGY SAVINGS 
•‘ 3 ESCCNT_CF..TI V£ DwLLLNS comfdrtaol 
PERCENT OF TIME HOT WATER A V A I L A L 


PERCENT 

KW 

PERCENT 


PERCENT 

KVY 

PERCENT 


KWH. 

ESTIMATE OF TOTAL 
KWH USED THIS 
HOUR' SAME AS 
ESTIMATED AVG. KW. 


EST. AVG. PERCENT 


KWH 


ST. AVG. PERCE 


EST AVG GAL/MIN 


EST AVG SAME 
UNITS AS DETAIL 


KWH. 

EST. OF TOTAL 
KWH USED THIS DAY 


EST. AVG 


KWH (EST. TOTJ 


EST. AVG. 





EST. AVG. 


EST. AVG 


EST. AVERAGE 


KWH. 

ESTIMATE OF TOTAL 
KWH USED THIS 
DAY 


EST. AVG. PERCENT 


KWH If ST TOT) 





KWH (EST. TOT) 


CST. AVG. 


EST. AVG PERCE.”* 1 


EST (EST. TOT) 


EST. AVG. 

TIME PERCENT 


i B w 'v 





































VALUE 1 


I 


START OF TIME 

HOUR/DAY 


VALUE 2 


, TIME 


VALUE 


TIME 


VALUE 


T 


time 4 end of 

HOUR/DAY 


• VALUE 1. VALUE 2. VALUE 3. AND VALUE 4. REPRESENT 
"GOOD" VALUES READ WITHIN THE SAME HOUR 

• "HOURLY COMPUTED VALUE [(Min ♦ IK 

VALUE ♦ (Mm 2 - Min ,). VALUER (Ming • Ming , 

VALUEg + (59 - Ming). VALUE 4 J 

• MIN; - MINUTE PORTION OF TIME; ( 0< M i n; < 59) 
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Figure 10. Weighting of Values in Computing Hourly /Daily Variables 
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3.9 CREATE HISTORY/ARCHIVE TAPES 


The input processing software shall provide the capability to create 
and maintain history and archive data (raw data and processed data) on 
magnetic tapes. Raw data received daily from the S/7 computer shall 
be written to disk storage and organized into a data set for each 
day's data. The corresponding site description data file containing 
calibration/conversion information shall also be written to the data 
set gn a dally basis. Cn a monthly basis, this data shall be written 
to magnetic tape for archival purposes. Magnetic tapes shall be 
cataloged to relate days of information with tape Identification for 
retrieval purposes. 

Processed data shall be maintained on tape for history purposes. 
Monthly, after all data for the month has been processed, the detail 
records for the month, organized by site ID, shall be stored on detail 
record archive tape(s). Hourly records for the month, organized by 
site id," shall be stored on hourly record archive tape(s). Daily 
summary records remain in the data base, thus there is no requirement 
to keep them on archive tapes. 
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3.10 CREATE INPUT SlftMARY REPORTS AND ERROR MESSAGES 


To assist the performance analyst and data base maintenance personnel, 
the Input Processing Software shall create input summary reports and 
error messages. To provide these reports and messages, the software 
shall: 

o Generate dally reports to specify the number of data base input 
records by site and scans 

o Generate a report to specify the number of records by site placed 

In monthly data base detail record history files 

q Generate a dally summary report to specify the number of sites 

processed and the number of sites for which processing failed 

0 Generate dally messages if a site Is dropped or a block of data 
Is dropped 

o Support user selection options for site summary reports on raw 

Input processing. These reports shall Include the following types 
of Information: 

- Number of blocks 

- Number of scans 

- Time of first and last scan 

* • 

Summary or errors in variables. 

0 Support user selection for error messages on Individual 

variable errors (3CK errors, out of limits, variable changing 
too fast, variable rejected) during raw Input processing. 

o Support user selection option for printing data base detail 
records created by raw Input processing. 

o Provide a report of callbratlon/converslon parameters for each 
remote site. Report shall Include: 

- Callbratlon/converslon data for each input parameter 

- History of changes In callbratlon/converslon data 
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4. FILE MAINTENANCE SOFTWARE REQUIREMENTS 


The file maintenance spftvare shall execute in the S/370-145 host 
computer and shall provide the capabilities required in support of the 
performance evaluation data base. The software shall execute in a 
Shared environment under control of the S/370 OS/MVT operating system. 

4.1 FUNCTIONAL REQUIREMENTS 

To support the management of the performance data base, the file 
maintenance software shall: 

o Update the data base from the output of Ihe Input 
Processing Software 

o Provide capability for manual input to the data base for data 
collection/addition/correction 

o Provide capabilities required in performance of data base 
maintenance, access, and update functions 

o Provide security of data base contents. 

The following paragraphs address the detailed requirements which must 
be satisfied. 


A. 2 AUTOMATIC UPDATE OF DATA BASE 


The file maintenance software shall accept the output of the input 
processing software and create the performance evaluation data base. 
The input to this software shall be of the format shown previously in 
Figure 9 and shall be sequenced by site identification and all data 
for each site shall be in time sequence. The input shall contain 30 
days information for each remote site and shall be stored onto the 
disk unit, within the host computer facility, which is dedicated for 
solar heating and cooling system evaluation data. Directories 
required for access/update of the contents of the data base shall be 
created during the update process. 

Errors encountered during creation of the data base shall be provided 
for data base correction activities. 
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4.3 MANUAL INPUT TO THE DATA BASE 


The performance evaluation data base shall contain non-instrumentation 
data relating to description and performance of solar heating and 
cooling systems. In addition, manual input for correction of data 
base contents shall be supported. Both terminal input and batch input 
techniques shall be provided. 

The manual Interface capability shall be used to generate initial data 
files within the data base and shall be used to enter non- 
instrumentation data, problem descriptions, problem solutions, and 
other text-type information. 

During the manual input of data, the software shall perform editing on 
format of input to ensure that incorrect data is not entered into the 
data base. Messages shall be provided to indicate erroneous input (on 
display tube from terminal input, and via printout for batch mode) . 



4.4 DATA BASE MAINTENANCE . ACCESS. AND UPDATE 

The normal data base aaincenance, access, and update capabilities 
shall be provided for support of the performance evaluation data base. 

The file maintenance software shall provide: 

o Predefined operations to be performed on the data elements 
when maintenance is being performed. 

o Interface between the data base processing language and user 
written routines for data editing. 

o Data field editing while performing file maintenance. 

o Indication of errors In data makeup for corrective action. 

o Statistics on system characteristics for use in improving . 
performance. 

o Ability to access multiple files within the same processing 
sequence . 

o Capability for keyvord/secondary indexing of data fields. 

o System recovery/restart. 

o Data migration (archiving) of data from the data base on selected 
basis. 

o Support of restructuring data files to allow for changes in either* 
file size or content. 

o Data base utility functions for data conversion. 
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4.5 DATA BASE SECURITY 




The file maintenance software shall provide security in access of the 
data within the data base. The data base security capabilities shall 
be utilized in either the terminal or batch mode of operation. 

Details of the security requirements are contained in the following 
paragraphs: 

Terminal Access 


Data base security within the terminal access mode shall consist of 
sign-on, password, and file classification security techniques. 

At sign-on to the terminal, the user shall specify accounting 
information and name. This information shall be verified for 
correctness, and if incorrect, a message shall be displayed specifying 
that incorrect accounting information has been entered. The user 
shall be allowed to retry three.. times before the terminal input is 
ignored. A sign-off shall be required before the terminal will be 
reactivated within the system. 

If a log-on is successful, a password shall be required before 
proceeding. Three consecutive errors in password entry shall result 
in terminal being ignored by the system. Error messages shall be 
provided to the terminal during password editing. 

Successful completion of password processing shall result in a user's 
being allowed to request that a data file be opened for access. 

If a data file open request is entered, the software shall ensure that 
the user has the authority to access the data file being requested 
through file classification. The software shall allow the user access 
to: (1) read only, (2) write only, or (3) both based on the access 
table within the system. If the user does not have proper file 
classification code, he shall not be allowed to address the data file, 
end an error message shall be displayed. 

Batch Access 

Security within the batch mode of operation shall be similar to that 
described above for terminal access with the exception of "sign-on" 
security which does not apply to batch operations. For password and 
file classification protection, erroneous requests shall result in the 
batch job being terminated and error messages being printed for user 
action. 

Access Authority 

Authority to access the data base shall be controlled via formal procedures. 
Management approval shall be required prior to releasing password information 
and shall be required to add user's identification to the access list. 
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5 . USER SUPPORT SOFTWARE REQUIREMENTS 

The user support software executes in the S/370-145 host computer and 
provides chose capabilities which are critical to the performance 
evaluation activity. Presentation of information in a form supporting 
evaluation and satisfying the needs of a diverse user community shall 
be the overriding objectives of this element of the software. 

5.1 FUNCTIONAL REQUIREMENTS 

The user support software shall utilize the contents of the 
performance evaluation data baSE to provide the following: 

o Information retrieval capability for report generation 
(non scheduled) 

o Plot capability for support of analysis activities and inclusion 
in reports 

o Generation of daily, monthly, and annual reports (scheduled output) 
o Generation of magnetic tapes 
o Terminal/Batch capabilities 

The detailed requirements in the above capabilities are described in 
subsequent paragraphs. 
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5.2 INFORMATION RETRIEVAL 


The user support software shall provide the user with the capability 
to access the data base contents on a non-scheduled basis for 
generation of reports/plots to support his daily analytical 
activities. An information retrieval language shall be provided to 
allow the user to generate queuries to satisfy his own unique 
requirements. The retrieval capability shall be supported in both 
terminal/batch modes of operation and shall provide the following: 

o Retrievals against single/multiple files. 

o Data qualification via user generated subroutines. 

o Terminal data entry/collection from desired files. 

o Batch processing of large data retrievals/updates. 

o Multiple answer files from one retrieval. 

o Versatile output formatting with headers, labels and boolean 
processing capability. 

o Library capability for temporarily storing queries for 
repetitive use. 

o Display statistical summaries of selected parameters. 
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5.3 PLOT CAPABILITY 


The ability to provide the performance analyst with plots of 
instrumentation shall be an essential capability within the user 
support software. The software shall provide the ability to: 

o Plot selected parameters versus time 

o Plot parameter versus parameter over time interval 

o Plot multiple parameters against time 

o Provide multiple plots on the same CRT image 

The Tektronix 4015/4631 terminal-hardcopy unit shall be supported by 
the software to provide both plots for analysis on the display and 
hardcopy of plots for inclusion in reports. 

Input to the plot support software shall be a file created through use 
of the information retrieval capability. The ability to process 
multiple input files to produce multiple hardcopy reports shall be 
provided. Interactive capability with data base for plots will not be 
required. 

Representative examples of plot requirements are shown in Figure 11. 


A -67 


n*n 


COLLECTOR INCIDENT SOLAR RADIATION 



HOT STOP AGE TANK TEMPERATURE - 



Figure 1 1. Terminal Graphs and Plots 


COLLECTOR SURFACE TEMPERATURE 



OUTDOOR AMBIENT AIR TEMPERATURE 
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5.4 GENERATION OP SCHEDULED REPORTS 


The user support 5*ftw«re shall provide the capability to access the 
data base on a planned basis for generation of scheduled output 
reports. The softaar? shall provide libraries of standard information 
retrieval queries v4uch create the reports in the required formats. 
After completion of the daily data base update, the daily summary 
reports shall be generated and will present data summarized on an 
hourly basis for analysis. 

On a monthly basis, the monthly summary reports shall be generated. 
These reports shall have data summarized to a dally basis, shall be 
analyzed for accuracy, and delivered to users for evaluation and 
archiving. 

Capability to generate annual reports shall be provided. Dally 
summarized data shall be summarized into months and the monthly data 
presented over the annual reporting period. 

A representative example of a scheduled summary report is shown in 
Figure 12. Reports shall be provided to MSFC, ERDA, and MSFC 
associate contractors. 
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SOLAR HEATING AND COOLING PROGRAM 


ERDA 1-0037 
12/16/76 


OAILY SYSTEM PERFORMANCE SUMMARY 


PROCESSING DATE: JANUARY 4. 1976 


SITE NUMUER: 

SITE LOCATION: 

SITE NAME: 

OPERATION START DATE: 
LATITUDE: 

LONGITUDE: 


1915 WAXLEAF GREEN. HUNTSVILLE. ALABAMA 35803 

% 

OCTOBER 17. 1976 

34.7°N 

UG.G°N 


COLLECTOR SIZE: 65 SQUARE METERS 
COLLECTOR TYPO: REVERE COPPER 
STORAGE SIZE: 1200 GALLONS 


STORAGE MEDIA: 
SYSTEM TYPE: 


100% WATER 

HOT WATER. HEATING & 
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DATE OF DATA: DECEMBER 16. 1975 


TOTAL SOLAR 
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Figure 12. Representative Scheduled Summary Report 


5.5 MAGNETIC TAPE GENERATION 


The user support software shall provide th# capability to generate 
magnetic tapes compatible with user (MSFC/£RDA/MSFC associate 
contractors) computer facilities. Magnetic tapes in either 9-track 
1600/800 BPI or 7-track 800 BPI formats shall be generated. The 
information retrieval capability shall be utilized to access the data 
bank to create data files containing the required data in the correct 
format. User support software shall be provided to access the data 
files and write the data to the magnetic tape for delivery to users. 


5.6 TERMINAL /BATCH CAPABILITIES 


In support of users, the user support software shall provide access to 
performance evaluation data bank contents via both terminal and batch 
modes. The terminal supported shall be IBM 3277 units located with 
the IBM facility (local terminals). An interactive terminal 
capability shall be provided for access and display of data base 
contents. Displays shall be text or numerical information and shall 
be used for on-line performance evaluation activities. Hardcopy 
outputs and graphic displays cannot be generated on the interactive 
terminals but shall be provided via the batch mode (hardcopy) and plot 
capabilities (graphic on the Tektronix 4015/4631 display unit 
dedicated to support of performance analysts within the IBM facility. 

The terminal processing software shall provide the user the capability 
to: 

o Generate and execute information retrieval queries 

o Execute predefined information retrieval queries 

o Submit batch Jobs via remote job entry 

o Use a display language to define output formats 

o Perform maintenance on existing data files 

The batch operating capability shall provide the capability to perform 
the following: 

o Generate and execute information retrieval queries 
o Execute predefined queries 
o Production of hardcopy reports 
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6. PERFORMANCE EVALUATION DATA BASE REQUIREMENTS 

The performance evaluation data base shall be located on disk storage 
and magnetic tapes within the S/370-145 host computer and shall 
contain all data files required in support of performance evaluation 
activities. Management and access to data within the data base shall 
be via the daua base management and user support software. 
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6.1 FUNCTIONAL REQUIREMENTS 


The performance evaluation data base shall be organized to provide 
each major data bank user with his own data file yet provide the 
capability to correlate information among the files. The data 
contained within the data base shall Include both automatically- 
entered and manually-entered data. 

The data base shall provide files for the following: 

o Remote site description 

o Remote site operational data 

o System analysis simulation/weather data 

o System Interaction data 

o Subsystem evaluation 

o Configuration management 

o Software development 

o Raw data file 

Each of the files shall have the following design requirements: 

Fixed Data Elements - Data fields, which represent record keys, 
site/system characteristics, site/system identification, 
geographical, and past climatological information, shall remain 
fixed within data set records for life of the Solar Heating and 
Cooling Development contract. These fields shall be protected 
from arbitrary access and Inadvertent destruction to avoid propa- 
gation of error throughout the remainder of the data base. 

Periodic Data Elements - Data values, which represent solar 
system end subsystem integration and testing data, and data 
collected from operational sites will recur on a fixed periodic 
basis as input to the data base. The periodic interval shall be 
one of the following: five minute sampling interval of raw data 

readings, summarization intervals such as hourly, dally, etc., 
and pre-defined intervals in accordance with the schedule for 
system and subsystem testing. Periodic data shall be pre- 
processed (converted to engineering units, limit checked, scaled, 
etc.) prior to being included in the data base. 

Variable Information - Variable data fields shall contain text 
and commentary information and also as pointers to data items in 
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off -lint storage. Of particular importance will be the 
maintenance of failure history information for each remote site. 

Grouped Data Elements - To simplify data manipulation and 
retrival, continuous fields of related data shall be grouped and 
secondarily named as one field when appropriate. For example, 
the latitude, longitude, and elevation of a site shall be grouped 
under one name, 'location', to facilitate data operations. 

Data Value Modes - Both alphameric and numeric data value shall 
be stored lr. the data base. Record elements which are defined as 
alphanumeric mode shall require EBCDIC characters to be stored as 
bytes. These fields shall not require mathematical processing. 
Record elements (fields or groups) containing numeric values 
shall require processing using mathematical operators. 

Data Set Record Sices - One record of each operational data set 
shall be equated with generated or collected data for each 6-hour 
period out of a 24-hour day. Since the site operational data set 
requires the largest data base storage, the maximum physical 
record size is determined by the volume of data remotely 
collected in one 6-hour period as shown below: 

1 Physical Record * One 6-hour period of data per site 

Period 1 00:00-06:00 hours 

Period 2 06:00-12:00 hours 

Period 3 12:00-18:00 hours 

Period 4 18:00 - 24:00 hours 

Number of recordings/hr ■ 12 (1 every 5 minutes) 

Number of data parameters read ■ 42 (maximum) per reading 
Avg. number of bytes per parameter • 4 (1 word) 

Total bytes per hour * 12 x 41 x 4 » 2016 bytes/hr 
Record Overhead ■ 16 percent 

Total Physical Record Size - 1.16 X 12,096 ■ 14K 

Catalogued Procedures - To ease the requirement on the user to 
supply all the necessary job control statements and language when- 
ever a system component is used, cataloged procedures shall be 
prepared. These procedures are sets of previously written job 
control statements which will require prior storage into the 
System Library, uniquely named, and automatically retrieved during 
execution. Examples of required procedures are those to generate 
routine and fixed format reports, such as daily, weekly, monthly 
and quarterly analysis and evaluation reports. 








Assembly and Higher Level Language Routines Support - The dace 
base user shall be provided Che flexibility to process his data 
directly from the data base and optionally update the data base 
from the calculated results. This requires that the user be 
provided temporary work files on which to score intermediate 
evaluations and redefine inputs to the data base. Usage of 
programming languages will require conforming to the programming 
linkage conventions as defined in the NIPS File Structuring 
User ' s Manual . 

Secondary Indexing Capability - Secondary indexing shall provide 
the user with the capability to index files in the data base by 
the contents of a field or fields other than the record key 
identification (e.g., cate/ system/site ID). The primary purpose 
of this capability is to provide a faster response time for 
qualifying records during retrievals. Representative fields 
which are required to be indexed due to their frequency of use 
are: 

o Subsystem (collector, storage, etc.) manufacturer's 

identification 

o Subsystem type identification 

o Subsystem material type identification 

o Subsystem cost category (economical, marginal, uneconomical) 

o Subsystem efficiency category (very high, high, average, low, 
very low) 

IBM Standard 370 Software - The Systen/370 Partition Data Set 
(PDS) access method snail be utilized to support software 
development and configuration management. The Partition Access 
Method allows rapid access to software modules and configuration 
ma^'pement reports by "name" alone. Each name and its associated 
data is a member of a PDS. 

Interfile Cutout - Interfile output (IFO) is the capability to 
combine data from several related files (data sets) during output 
processing. This capability shall be required when the user 
requires information from several files to satisfy a complex 
information retrieval query. 
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6.2 REMOTE SITE DESCRIPTION 


The remote site description file shall contain physical chracteristics 
of the remote site, description of the solar heating and cooling 
system, auxiliary power costs, and ocher characteristics needed to 
evaluate performance of the system. Since no instrumentation data is 
included within this file, manual input shall be required to generate, 
update, and maintain the file. Correlation information shall also be 
Included to allow interfile access to satisfy complex queries 
requiring information from several files. Pointers shall also be 
included for correlation to off-line documents pertinent to each site. 

The remote site description file shall reside on the disc and be 
immediately available throughout the life of a remote site. 
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6.3 REMOTE SITE OPERATIONAL DATA FILE 


The remote site operational data file shall contain the daily 
processed instrumentation data from each remote site. Because of the 
volume of data, only one month's input shall be maintained on disk for 
immediate access. Data more than one month old shall be maintained on 
magnetic tape. 

This file shall be organized by remote site ID and operational data 
shall be in chronological order over the month interval. In addition 
to the detailed instrumentation data, the file shall contain 
hourly summaries (over previous month interval), daily summaries 
(over life of remote site), performance evaluation parameters computer 
during the input processing activities, and correlation information to 
support interfile queries. This file shall also contain correlation 
information to files which contain manual input such as non- instrumented 
data, site anomalies, failures, etc. The file shall be automatically 
update a on a daily basis. 

Because this file shall contain the data of most interest to the 
performance analyst, the design shall optimize data organization to 
minimize retrieval/ access times in generation of reports/plots. 
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6.4 SYSTEMS ANALYSIS S DfULATION /’•’FATHER DATA 


In the prediction of system performance at a remote site, systems 
analysis simulations will be performed. The results of the simula- 
tions performed for reference with operational performance shall be 
maintained in this data file, leather data (US Weather Service Data) 
used during development of reference predictions shall reside on 
magnetic tapes; however, the data file shall contain reference to 
weather data used. 

The results of remote site predicted performance simulations shall be 
provided in summary form for correlation with data reports generated 
from the remote site description ana remote site operational data 
files. The results of reference simulations shall be organized by 
site ID and automatically entered into the data file by the simula- 
tion software. 
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6.5 SYSTEM INTEGRATION’ DATA 


Each solar heating and cooling system installed in remote sites shall 
be assigned a unique identification for evaluation purposes. The 
file shall contain the identification of subsystems comprising the 
system, characteristics of the system as determined during testing or 
from vendor provided information and pertinent test data. 

This data file shall be manually updated and shall reside on disk for 
lifetime of the solar heating and cooling system. 

6.6 SUBSYSTEM EVALUATION’ DATA 


Each subsystem provided to IBM by MSFC for use in systems integration 
shall be included within this data file. Characteristics of the 
subsystem (both vendor data and MSFC test results) shall be included 
within this data file. The file shall be organized according to 
subsystem type (collectors, storage, hot water, cooling, heating, 
etc.) . 

The data file shall reside on disk and shall be manually maintained. 
The file entry for each subsystem shall remain active throughout the 
utilization of the subsystem. 

6.7 CONFIGURATION MANAGEMENT 

The configuration management data file ;hall provide the capability to 
maintain historical data pertaining to change activity. Both hardware 
and software changes 'shall be maintained on disk within the host 
computer. Upon release of first articles for use, an entry within the 
configuration management data file shall be established. All changes 
made to these baselines shall be entered into the file along with 
associated documentation. 

6-8 SOFTWARE DEVELOPMENT DATA 

The software development data file shall contain the library of 
baselined software deliveries and shall be modified only through 
configuration management approval. 3oth source and load modules shall 
be included and shall be identified by ’nane 1 within the file. 

Security shall be provided to ensure controlled access to the file. 

6.9 RAW DATA FILE 


The Raw Data File shall reside on magnetic tape and disk storage 
within the IBM facility and shall contain a history of all raw data 
received from each remote site. The data less than one month old shall 
be maintained cn disk ar.d shall be dumped to magnetic tape on a 
monthly basis. Raw data shall be organized according to day of 




receipt and shall be sequenced In the order In which remote site data 
was collected. 


7. SOFTWARE VERIFICATION REQUIREMENTS 


Verification of the CDPS software shall be performed prior to the 
overall CDPS becoming operational. This verification shall be 
performed while utilizing the CDPS hardware and shall consist of three 
phases: 

Development Verification - Analysis and testing performed to 
ensure that elements of the CDPS software satisfy requirements. 

Qualification Verification - Testing to ensure that the software 
system satisfies overall design requirements. 

Acceptance Verification - Testing to ensure that the software 
system satisfies normal operational requirements. 

During qualification and acceptance verification, test procedures 
shall be prepared and followed.-- Test results shall also be 
documented. 

Details of the verification plan and approach are contained in the 
"CDPS Verification Plan" and other CDPS documentation. 


APPENDIX A 
PROGRAMMING 
STANDARDS 
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INTRODUCTION 


During Che development, documentation, and maintenance activities 
associated with providing an operational CDPS capability throughout 
the lifetime of the demonstration program, a set of programming 
standards shall be utilized. The use of these standards results in an 
organized and systematic approach which provides reliable software 
which is easily understood and maintained. 

1.1 SOFTWARE IMPLEMENTATION STANDARDS 

The standards/conventions/procedures established for the software 
implementation phase are to provide continuity among the many 
programmers assigned. The implementation phase is usually the most 
difficult to control because of the individuality involved. A 
significant objective of standards is to establish a more structured 
approach to the coding process and to obtain program listings more 
easily understood and transferable. 

Standards to be utilized during software development are discussed in 
more detail in the subsequent paragraphs. 

1.1.1 Structured Coding Technique 

In concept, structured coding is an extension of the approach utilized 
in hardware design and development, of constructing complex circuits 
from elementary AND, OR, and NOT gates. The software analogies to the 
hardware components are: 

o Sequence of two operations. 

o Conditional branch to one of two operations and return. 

Programs written using structured code can be literally read from top 
to be -tom typographically; there is never in line branching as is 
typical in trying to read code which contains "GO TO" statements. 

An important task in assuring that a program meets its design 
requirements is the detailed audit procedure. Since this audit is 
best performed by someone not initimately in the program development, 
readability of the code is of prime Importance. One of the advantages 
of the structured code technique is that it provides a basis for 
systematic reading of the program. The reading sequence within each 
segment is strictly from top to bottom. As a result, audit procedures 
are made more systematic and result in higher software reliability. 
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1.1.2 Program Support Library 

The programming support library (PSL) is a set of clerical and 
computer procedures designed for use in a software development 
environment, plus the clerical support needed to make it work. The 
principal objective of the library is to provide up-to-date 
representations of the programs and test data in both computer and 
human readable forms. The design of the procedures permits most of 
the clerical and recordkeeping operations associated with programming 
to be Isolated from the programmer. 

The principal advantages gained from use of the program library on 
software development are: 

o Frees the programmer from clerical duties. 

o Centralizes the software system development activity. 

o Provides discipline to system development process. 

o Increases management visibility and control over software 
development . 

1.1.3 Top-Down Developmen t 

The top-down development technique is the application of the natural 
system design approach. This technique requires the software control 
architecture and Interfaces be established and developed first and 
succeeding levels of 'detailed logic implemented in a downward fashion. 
Top-down development provides an ordering which allows for continual 
software integration of system components and provides for well- 
defined interfaces at each level. 

In top-down development, the system is organized into a tree stucture 
of segments. The top segment contains the highest level of control 
logic and decisions within the program and either passes control to 
lower level segments, or identifies lower level segments for inline 
inclusion. The process continues for as many levels as required until 
all functions within a system are defined in executable code. 

Many system Interfaces may occur either through data base definition 
or calling sequence parameters. The top-down approach requires the 
data base definition statements be coded and actual data records be 
generated before exercising any segment which references them. 

The top-down approach provides the capability of evolving the product 
in a manner which maintains the characteristic of being always 
operable, modular, and always available for the successive levels of 
testing that accompany the corresponding levels of implementation. 

The quality of a system produced using this approach is increased, as 
reflected in fewer errors in the module Integration process. 
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Inconsistencies are eliminated, and lower level segments can be 
generated by referencing implemented code. 

1.1. A Coding Standards 

A critical item in the production of software which is easily 
understood, transferable, and maintainable is the establishment of 
standards to be utilized during the coding process. The output of the 
coding process, the program listing, is the most highly utilized 
portion of the documentation package and must be controlled through 
the application of standards. High order languages, which support the 
structured programming concept, shall be used. 

1.2 SOFTWARE TESTING STANDARDS 


The software shall be tested in an atmosphere which emphasizes the 
need for planning of testing. Because of the emphasis of high quality 
in the operational use of software, a highly structured approach must 
be followed to ensure chat, in addition to satisfying user 
requlremens, the operational system satisfies the objectives of 
maintainability and transferrability . 

1.2.1 Top-Down Testing 

Top-down testing concentrates all testing activities on verifying 
functional capabilities of the software in the system environment. 

The benefits are increased system reliability, reduced testing cost, 
and a more visible testing process. 

Using the top-down approach to software system development and a 
programming support library, all tests shall be performed in the 
system environment. The top-down approach ensures that all interfaces 
needed to execute are available when testing begins. Hence, program 
interface assumptions are never made and all testing verifies the real 
interfaces. Testing new programs or program changes in a temporary 
mode, without permanently modifying the systems, is easily done. When 
the program is tested, it shall be incorporated into the master system 
via the system build after receiving IBM management/NASA review for 
change control. Performing all tests against the master system 
accomplishes integration testing continuously as the functional 
capabilities are verified. 

1.3 SOFTWARE DOCUMENTATION STANDARDS 

The software documentation shall be generated in a continuing fashion 
throughout the software development phase. As was discussed, the 
programming support library will provide the central facility for 
generation of documentation. The primary documentation output shall 
consist of: 
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o Software Requirements Document 

o Software Design Document 

o Users Manual 

1.3.1 Structured Documentation 

Documentation consists of the products of the definition and design 
activity. Implementation, verification, validation, and delivery will 
only modify design documentation. Employing top-down design will 
require that documentation be developed in a hierarchical, tree-like 
fashion. Top-level descriptions will reflect functional software 
operations. These high level descriptions will, in turn, be explained 

and/or expanded by lower level descriptions, and the process continued 

to the lowest module level. This produces documents that can be read 
and understood at any level. In addition, physically seaprate 
documentation required by volume can be done without impacting 
readability. 

Readability shall be provided by describing software operation in the 
following manner: 

o Visual Table of Contents 

o Overview diagrams 

o Detail diagrams 

o Supporting text and annotated data 

Functional documentation proceeds from a top level Visual Table of 
Contents diagram down to a basic nodule diagram of input, Processing, 
Output, functional chart. For each task to be performed, a module 
diagram shall be developed. 

1.3.2 Flow Chart Standards 


Although use of high-level language for software development reduces 
the usefulness of flow charts, flew charts will be required for 
deliverable documentation. The flow charts will depict how the 
software performs in the satisfaction of requirements. 

To provide ease of correspondence between program listings and flow 
charts, the plcture-on-a-page technique applied during coding will be 
applied to the generation of flow charts. Through this technique, a 
flow chart will exist for each routine of the software, and both the 
flow charts and listing will provide direct correspondence. 
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APPENDIX B 


CDPS OPERATIONS APPROACH 


1 . 


INTRODUCTION 


The CDPS must satisfy the processing and user support requirements 
resulting from dally data collection from all remote sites. To 
provide data to analysts by the beginning of first shift each day, an 
operations procedure has been established and is discussed in the 
following paragraphs. 

1.1 DATA COLLECTION 

SDAS data collection will occur during the evening hours (beginning at 
2000) . The collecting will continue until approximately 2330 (60 
sites require approximately 3.5 hours) and upon completion, will be 
transferred via data link to the S/370-145 (requires 30 seconds) . 
Computer operator intervention will be performed at the start of data 
collection time period to initiate the System 7 software. During the 
data collection time period, the communication interface computer 
console will be monitored for indications of telecommunications 
progress in contacting and receiving data from the SDAS equipment. In 
the event of communications difficulties, effort will be undertaken to 
resolve the problem during the hours dedicated to data collection. 

The communication operations personnel will be guided in the problem 
resolution by directions frcn the S/7 software analyst. The operator 
will, as required, interface with the MSFC Telecommunications Systems 
Status Center (TSSC) for resolution of communications difficulties. 

1.2 DATA PROCESSING 


Data processing on the host computer will occur between the hours of 
midnight and 0700 each day in order to provide error reports and 
summary reports and performance reports for SIMS analysts at the 
beginning of first shift (GdCO) . The Input Processing portion of the 
CDPS software system will be executed, upon completion of data 
communication and retrieval by the Communication Interface computer, 
and will process the forwarded data from the System/7. All processed 
data containing no errors will be converted into engineering units, 
performance calculations performed, and data cade ready for insertion 
into the performance evaluation data bank. Errors encountered during 
processing will be flagged such that erroneous data will not be 
entered into the data base, and error messages/reports will be 
provided for analysts. 

1.3 DATA BANK PROCESSING 

Upon completion of the Input Processing phase, the Data Base/User 
Support software will be executed in a batch environment under control 
of computer operations personnel. This processing will be 
accomplished in a manner to satisfy data availability requirements and 
output distribution. 
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To ensure timely completion, a high priority will be assigned to the 
processing of input data and will be monitored by operations 
personnel. If conflicts occur, the processing will be assigned the 
highest priority and will override any other processing. 

Archiving of data will be provided through the use of software within 
the host computer. Raw data, processed data, and performance reports 
will be maintained within the computing facility and will be 
distributed as required for analysis/storage. 

1.4 USER SUPPORT 


User support will require that the data base management software allow 
ready access to the data base contents via local terminals and support 
batch job access to data for special analysis activities. When the 
IBM performance analyst requires a terminal capability to access the 
performance evaluation data base the computer operations personnel 
will, upon request, Initiate the terminal processing capability of the 
NIPS 360 software. This will free computer resources (core memory) 
for use by other processing requirements Instead of tying those 
resources up when terminal activity is not required. 

1.5 DATA BASE MAINTENANCE 


In addition to the daily scheduled updating of the Performance 
Evaluation Data Base with input from the Input Processing Software 
there will be the capability to perform selected maintenance on an as 
required basis. 

1.5.1 Error Correction 


Error conditions on data fields within the data bank corrected during 
first shift will be entered into the data base via local terminals 
(for small data volume) or via batch Job submission. Upon completion 
of error correction, fhe performance evaluation data within the data 
base will be formatted and written to magnetic tape for transfer to 
the MSFC Solar Energy Data Base. 

1.5.2 Non-Instrumentation Data Handling 

Data elements to be added to the data base which are not gathered by 
the SDAS and processed in the CDPS, such as site location, site 
equipment availability, weather data, etc., will be entered into the 
data base via terminal or batch mode using the NIPS-360 File 
Maintenance capability. This will allow for text type data to become 
part of the data base and available for reporting purposes. 
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1.0 


INTRODUCTION 


The Centrel Date Processing System (CDPS), through its hardware and software , 
shall provide the data collection, data processing, data archiving, and data 
distribution functions associated with performance evaluation of Solar Heating 
and Cooling Systems. The hardware, included within the CDPS, shall reside 
at IBM's FSD facility at Huntsville, Alabama and shall consist of two elements - 
a communications interface configuration and a host computer configuration. 

The performance specifications associated with this hardware, in support of the 
Systems Integration of Marketable Subsystems (SIMS) contract, are discussed 
in the following sections of this performance specification document. 

2.0 TYPE OF HARDWARE 

The hardware, to be used within the CDPS, shall consist of comnercially 
available hardware. 
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3.0 COMMUNICATION INTERFACE CONFIGURATION 

The Conmunication Interface Configuration shall provide: 

(1) Hardware required to interface with the Site Data Acquisition 
Subsystem (SDAS) via telephone lines for data collection. 

(2) The computational capability to control automatic call-up 

of each remote site on a daily basis, to control communication 
protocol with the SDAS, perform error checks on incorrect 
data, format data for subsequent processing on the host 
computer configuration, and store data for transmission to 
the host. 

(3) Input/output capability for operator intervention in event 

of errors and for logging of communications activity and error 
conditions. 

(A) A multiprogram environment for software execution. 

(5) Hardware for transmission of recorded data to the host 
computer configuration. 

(6) Mass storage for temporary storage of recorded data. 

(7) Operational environment which requires minimum operator 
support during the data collection activities. 

The performance specifications relative to the above capabilities are discussed 
in the following paragraphs: 

3.1 SDAS INTERFACE 

The SDAS interface hardware shall provide the capability to: (1) accept 
automatic dial signals from the communication interface computer, (2) perform 
the automatic dial function, (3) provide interface to a modem compatible with 
the modem contained within the SDAS, (4) receive data from the SDAS via the 
telephone lines, and (3) interface the data to the communication interface 
computer. A feedback mechanism shall exist in all hardware for signalling 
correct/incorrect operation. 

The hardware associated with the above functions shall consist of: 

(1) Teleprocessing multiplexer (TPMM) for computer controlled 
operations. 

(2) Auto-call unit to support automatic dialup feature. 

(3) Modem for telephone line Interface. 

The specifications of these hardware elements are discussed below. 
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3.1.1 Teleprocessing Multiplexer Performance Specifications 


The Teleprocessing Multiplexer shall provide the following capabilities in 
support of computer functions: 

(1) Software selection of operation (asynchronous mode for SIMS) . 

(2) Internal mode of clocking to support asynchronous transmission. 

(3) Receive/ transmit at 1200 Baud Rate on telephone. 

(4) Automatic call of Remote Sites under software control. 

(5) Interrupt communication processor on each byte of data 
transmitted/received (serial to parallel and parallel to 
serial conversions) . 

(6) Status information regarding comnunications status. 

3.1.2 Automatic Call Unit Specifications 

The Automatic Call Unit (ACU) shall accept the above signals from the TPMM 
hardware under control of the computer software and perform the Automatic 
Dial Functions. The Automatic Call Unit shall provide the TPMM with control 
information regarding the dial function. 

The sequence of operations between the TPMM and the Automatic Call Unit shall 
consist of: 

(1) Call Request (CRQ) line - activated by the computer to indicate 
that a call is to be placed. 

(2) Present Next Digit (PND) - activated by the ACU to signal the com- 
puter that the ACU is ready to accept the next digit for dialing. 

(3) Digit leads (NB1, NB2, NB4, NB8) - activated corresponding to 
the digit to be dialed. 

(4) Digit Present (DPR) lead - activated by the computer to signal 
that a digit has been placed on the Digit leads (NB1-NB8). 

(5) Data Line Occupied (DLO) lead - indicates to the computer 
whether the line is busy or not. 

(6) Abandon Call and Retry (ACR) lead - indicates to the computer 
that the called party does not answer or that, for some reason 
or other, the call is not completed. 

(7) Data Set Status (DSS) lead - activated by the ACU when the con- 
nection has been established. 


The ACU within the CDPS shall be Bell 801 or equivalent. 


B-4 


7933190 


3.1.3 Modem Specifications 

The modem within the CDPS shall be the Bell 202C or equivalent and shall be 
compatible with the modem within the SDAS. 
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3.2 


COMPUTER PERFORMANCE SPECIFICATIONS 


The conmunications Interface computer shall provide the control. Interface, and 
application programs necessary for complete control of the Conmunications 
Interface. The computer shall be Interrupt driven, provide cycle capture of 
data to memory, and have growth potential In both storage and processor CPU 
cycles . 

3.2.1 Processor CPU Specifications 

The CPU shall provide support for priority level processing through the use 
of an interrupt handling system within the hardware. When an interrupt 
occurs, the current status of the processor shall be automatically saved 
within specific save areas for continuation of processing after interrupt 
servicing. Four levels of priority processing shall be provided with the 
capability to define 16 sublevels of priority within each primary level. 

The instruction set provided by the CPU shall include the following classes 
of instructions: 

(1) Load and Store 

(2) Arithmetic 

(3) Logical 

(4) Shift 

(5) Branch 

(6) Regis ter- to-Regis ter 

(7) Input/Output 

The CPU shall be capable of handling multiple input lines simultaneously. 

The CPU shall perform parity checks on all data stored or retrieved from the 
Memory Unit of the computer. An odd-parity technique shall be provided. 

The CPU shall provide capability for addressing storage and for maintaining 
computer status within the computer. 

The following registers and indicators shall be provided: 

(1) Storage Address Register 

(2) Instruction Address Register 

(3) Index Registers 

(4) Accumulation Registers 
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(5) Interrupt Registers 

(6) Carry Indicator 

(7) Overflow Indicator 

(8) Result-Zero Indicator 

(9) Result-Even Indicator 

(10) Result-Positive Indicator 

(11) Result-Negative Indicator 

(12) Interval Timer Registers 

3.2.2 Memory 

The memory of the computer shall be sufficient to support the anticipated 
needs of the software (approximately 24K 16-bit words) and shall provide 
the capability for expansion through field modification to the baseline 
system. Maximum required memory shall be 65K 16-bit words. 

3.3 INPUT/OUTPUT SPECIFICATIONS 


A complement of peripheral I/O devices shall provide support to th* software 
executing in the processor to satisfy the operational requirements of the 
CDPS. 


3.3.1 Operator Console 

The operator console shall provide hard copy for Information inquiries, status 
messages, memory dumps, and control and maintenance of the Communication 
Interface Software. 

3.3.2 Direct Access Storage 

A direct access storage device shall provide on-line storage for the 
Communications Interface Software and provide temporary storage for incoming 
input data. The direct access dish shall provide the capability to store 
information from 60 sites. 

3.3.3 Additional Devices 

The Communication Interface Processor shall have adequate growth capability 
and flexibility in terms of new I/O modules /devices. This growth shall be 
supported by the initial computer architecture and shall not require any 
significant reprogramming or hardware design effort. 

3.4 HOST COMMUNICATIONS 

An interface or data link from the Communication Interface Processor to the 
host computer shall be provided. The communications interface shall not 
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require constant host communication end shell support e stend-elone 
environment. The host communication link shall be a coaxial cable, 
and the distance supported shall be less than one mile. 

3.5 OPERATIONS 

After manual initiation, the communication Interface configuration shall be 
capable of unattended operation during daily data collection from remote sites. 
In the event of errors which cannot be circumvented under automatic control, 
operator intervention shall be required. 
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HOST COMPUTER PERFORMANCE SPECIFICATIONS 


The host computer shall provide the capabilities, through Its peripheral devices 
and processing capabilities, to create, support and maintain the SIMS perform- 
ance evaluation data base. The host computer shall receive remote site data 
from the communication Interface computer over the Host/Communicatlons 
Interface data link and accept manual Inputs via cards or terminals for 
non-lnstrumentatlon data. The following sections specify the functional 
performance requirements of these elements. 

4.1 MAIN MEMORY 

Main memory shall provide the host computer with fast access, directly address- 
able storage of data. Main memory shall be of sufficient size to allow both 
SIMS data and programs to be loaded and processed. Main memory shall also 
have growth capability. The maximum storage requirements Is estimated to be 
256K bytes. 

4.2 CENTRAL PROCESSING UNIT 

The CPU shall be the controlling element for the host computer and shall 
provide facilities for: 

o Addressing main storage 

o Fetching and storage of data 

o Executing instructions 

o Initiating communications between main storage and I/O 

devices 

The CPU shall support both fixed and floating point arithmetic operations as 
well as logical operations and shall be sufficient speed to support the SIMS 
data processing requirements. 

4.3 INTERRUPTS 

The host computer shall have an Interrupt system to allow efficient use of 
I/O devices and for dynamic and fast response to peripheral equipment 
requirements. The interrupt system shall be used in a manner that results 
In a multi-program environment for the host computer. 

4.4 INPUT/OUTPUT 

The host computer shall have an input/output system that will adequately 
handle SIMS data transfers between main storage and the I/O devices. The 
Input/output system shall be flexible and allow for additional devices to 
be added with minimal system Impact. 
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4.4.1 I/O Channels 


Channels ere the direct controllers of I/O devices and control units. The 
host computer shall provide channels with the ability to read, write, and 
compute and relieve the CPU of the cask of directly communicating with the 
I/O devices. 

4.4.2 Direct Access Storage 

The host computer shall have direct access storage available to provide 
auxiliary storage for the performance evaluation data base and off-line 
storage for program storage. Direct access space required for SIMS Is 
estimated to be 200 million bytes. 

4.4.3 Display Terminal 

The host computer shall provide high speed, visual. Interactive communications 
between the host computer and the user via display. The terminals shall provide 
the SIMS user with the means for entry and change of information In .he host 
computer. The Interactive mode shall be provided via IBM terminals. Graphics 
capability shall be provided via a Tektronix 4015/4631 Display Unit or equivalent. 

4.4.4 Magnetic Tape 

The host computer configuration shall support the production and delivery of 
magnetic tapes containing performance evaluation data. These tape units 
shall support 9-track 1600/800 BPI density and 7-track 800 BPI density. 

4.4.5 Printer 

The host computer shall provide high-speed printers (1100 lines per minute) for 
creation of reports to be delivered to users of performance evaluation data. 

4.4.6 Card Reader/Punch 

The host computer shall provide a card reader /punch for program and data 
input to the system. 

4.4.7 Communications Interface 

A communication data link shall be provided from the host computer to the 
communications interface configuration for high-speed transfer of data collected 
and buffered by the communications Interface (see Paragraph 3.4). 

4.5 OPERATIONS 

The host computer shall be shared with other users. To Insure that SIMS data 

processing Is processed within specific time constraints, a high priority level 
will be assigned. 
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The Central Data Processing System (CDPS), which Is comprised of both hardware 
and software, provides the essential capabilities of data collection, data 
processing and storage, and data user support for the SIMS Program. Because 
of Its criticality in Solar Keating and Cooling System performance evaluation, 
the system must be verified prior to becoming an operational element of the 
program. 
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The objectives of the CDPS verification activity are to ensure that each 
element of the system, as well as the overall system, satisfies or exceeds the 
requirements established lr. the CDPS Performance Specification Documentation. 
The verification activity, therefore, requires a systematic approach to analy- 
sis and testing and sufficient documentation to provide traceability of test 
results. The approach, however, must ensure maximum confidence In system 
operation with the minimum expenditure of resources. 


Within this document, all descriptions of and references to the CDPS hardware 
configuration are only to facilitate explanation of the software requirements 
and not to control the configuration of the hardware^ The CDPS hardware Is 
controlled by I3M and Is used for support of multiple contract programs. To 
support this varying utilization environment, IBM must maintain the flexibility 
to modify the configuration as required. Because of this flexibility require- 
ment, the CDPS hardware configuration may vary during the performance of the 
SIMS contract, but the capability to satisfy all SIMS processing requirements 
contained within the CDPS Hardware Performance Specification will be maintained. 

1.1 PURPOSE 

The purpose of this CDPS Verification Plan is to define the approach to be 
utilized in verification of the CDPS and to delineate the schedules to be 
followed In providing a verified CDPS. 
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1.2 SCOPE 

This verification plan addresses the verification activities required of the 
CDPS* In addition, configuration control techniques and test plans are de- 
fined to provide management and NASA visibility into the verification activities. 

1.3 APPLICABLE OCCIDENTS 

The following documents are required in support of CDPS verification: 

(1) CDPS Hardware Performance Specification Document 

(2) Systea/7 Functional Characteristics 

(3) Site Data Acquisition Subsystem Performance Specification 
(A) Guide to S/370-1A5 

(5) Systen/370-lA5 Functional Characteristics 

(6) NMCS Information Processing System Manuals 

(7) S/7 Teleprocessing Description 

(8) CDPS Software Performance Specification 

(9) Programming Guide for System/7 Teleprocessing Feature (GC3A-15A9) 
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2.0 C6PS description* 

Within the overall Solar Heating and Cooling Demonstration Program, the CDPS 
performs the following functions: 

Data Collection - The CDPS daily collects instrumentation data from all remote 
sites via standard voice-grade 1200 Baud telephone lines. In addition, non- 
instrumentation data available from MSFC, ERDA, HUD, etc., which is needed in 
performing overall system evaluation, is collected via manual means. 

Data Processing - The CDPS accepts raw data, as collected by the data collec- 
tion function, and performs the data processing functions required to transform 
the raw data into processed information for use in system evaluation/analysis 
activities. The CDPS also provides the resources to maintain a performance 
evaluation data base, containing both raw data and processed information, for 
use in support of performance analysts. 

Data Archiving - To provide capability for detailed analyses of system perfor- 
mance and to maintain data for historical purposes, the CDPS provides the 
capabilities to archive data collected and processed. Both raw data and pro- 
cessed data is retained on magnetic tape, ar.d formal reports are archived in 
a library. 

Data Distribution - In addition to collection, processing, and archiving of 
data, the CDPS provides the essential function of distributing the data to the 
appropriate organizations. Distribution is in the form of printed reports, 
data plots, and magnetic tapes. 
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3.0 VERIFICATION APPROACH 

The verification of the CDPS will consist of a systematic testing/analysis 
approach which will ensure that system specifications/requirements are achieved 
or exceeded. Test procedures will be generated and followed during testing of 
each CDPS component and test results will be documented in a qualification re- 
port for review by management and MSEC. Verification cross-reference matrices 
will be used to ensure that all CDPS requirements/specifications are addressed 
during verification. 

Three phases of verification will be performed on the CDPS as defined in the 
following paragraphs: 

DEVELOPMENT - Analysis and testing of design approaches to ensure that approach 
selection will meet system specifications. 

QUALIFICATION - Analysis and testing of CDPS to design limits. Performed prior 
to entry to acceptance testing of the system. 

ACCEPTANCE - Testing of the operational CDPS as a system to ensure that over- 
all system satisfies system performance specifications'. 

The development and verification activities associated with the CDPS are shown 
in Figure 1 . 
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4.0 DEVELOPMENT /VERIFICATION SCHEDULES 


The CDPS is scheduled to be fully operational by 9/1/76. To achieve this 
program milestone, development and verification schedules have been defined 
and are shown in Figure 2. Discussion of the schedules is given in the 

following paragraphs. 

« 

4.1 DEVELOPMENT SCHEDULE 

Development activities have teen scheduled to provide software elements which 
have undergone preliminary development verification activities by 7/1/76. 

4.2 VERIFICATION SCHEDULE 

Development verification will be accomplished during June on individual software/ 
system elements and during July on system integration activities for the overall 
CDPS. 

Qualification verification will commence on 8/1/76. and will extend until 
approximately 8/25/76 . During this period detailed verification will be 
performed to test the system to design limits. 

Acceptance verification will commence on 3/25/76 and extend to 9/l/ 7 6. Upon 
completion of acceptance verification, the CDPS will be considered operational 
to support the overall program. 

















5.0 TESTING CONFIGURATION /UTILIZATION 


The testing configuration for use in verification of the CDPS capabilities 
relating to data collection/data processing/data base update/user support is 
shown in Figure 3. As can be seen in the figure, the configuration consists 
of the following elements: 

o System/7 Test Software 

o Controlled Signal Generation Equipment 

o Prototype Site Data Acquisition System (SDAS) 

o Telephone Line Interface 

o Communication Interface Configurations 

o Host Computer Configuration 

o Performance Evaluation Data Base 

A description of each of these elements and the rationale for their use during 
verification activities is discussed in subsequent paragraphs. 

5.1 SYSTEM/ 7 TEST SOFTWARE 


To provide the CDPS verification activity with reasonable sensor data, a 
System/7 test software package will be required. This software will allow an 
SDAS sensor configuration to be simulated for the purpose of generating CDPS 
test data. These simulator signals will be recorded for reference with CDPS 
output. The use of the System/7 software for sensor simulation results in a 
significant reduction in CDPS verification complexity and provides flexibility 
to easily reconfigure the simulation to address varying SDAS applications 
(increased sensors, varying formats, etc.). 

5.2 CONTROLLED SIGNAL GENERATION EQUIPMENT 

The Controlled Signal Generation Equipment will be utilized to provide labora- 
tory controlled voltages to the input multiplexer channels of the SDAS and 
thus will simulate signals which would be generated by sensors. This simula- 
tion capability is required because no sensors are connected to the SDAS until 
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o VARY VOLTAGE LEVELS 
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SITE DATA 
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o SPEED UP COLLECTION 
o CREATE TAPE CASSETTE WITH 
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REPORTS 
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CAPABILITY TO TEST: 

O RAW DATA ARCHIVING 
o RAW DATA PROCESSING 
o ERROR DETECTION 
o OATA BASE UPDATING 
O USER SUPPORT CAPABILITIES 


CAPABILITY TO TEST: 
o TELEPHONE INTERFACE 
O AUTOMATIC DATA COLLECTION 
o ERROR PROCESSING 
o REPORTING 
o DATA TRANSFER TO HOST 


PERFORMANCE 
EVALUATION 
OATA FILE 


Figure 3. j Test Configuration for Data Collection/Data Processing/Data Base Update/User 
Support Verification 
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either system testing at MSFC or installation at a remote site. In support of 
CDPS verification activities, the Controlled Signal Generation Equipment will 
have the following capabilities: 

o Place voltages onto selected input multiplexer channels of SDAS 
o Support Interface to all input multiplexer channels 

5.3 PROTOTYPE SITE DATA ACQUISITION SYSTEM (SDAS) 

The prototype SDAS will provide the capability to read the simulated sensor 
inputs from the Controlled Signal Generation Equipment and record them on 
cassette tape for subsequent transmission via telephone lines. The prototype 
SDAS will provide the capability to reduce the sample time to 8 seconds to 
speed up the data recording process (24 hours of data gathered in .6 hours) 
and reduce significantly the duration of tests. 

5.4 TELEPHONE LIME INTERFACE 

• - e ... 

To simulate the operational CDPS environment, telephone lines are provided for 
communication with the protototype SDAS. Two lines C& local line and an IBM 
tie-line) will be utilized during verification. The local line vill be used 
for development verification to perform debug of SDAS/communication Interface 
configuration Interface. The use of a local line reduces communication line 
errors and tnu3 provides a more controlled environment. During qualification 
and acceptance verification testing, the IBM tie-line will be used to simulate 
the use of a long-distance telephone line. These lines are not of high- 
quality and will provide a realistic testing environment. Calls to the proto- 
type SDAS via the tie-line will be routed to New Jersey and back to the 
Huntsville facility. This technique is widely used within IBM to test commu- 
nications between teleprocessing elements and presents a worse-case telecommu- 
nications environment for testing. 




5.5 COMMUNICATION INTERFACE CONFIGURATION 

The communication interface configuration will contain the operational hard- 
ware and software undergoing verification. The operational system will per- 
form in an unmodified form and will collect data from the prototype SDAS via 
the telephone interface equipment. Communication reports/error messages 
obtained during data collection can be compared to the reference data provided 
during the sensor simulation/ SDAS data gathering phase. Upon completion of 
data collection, the data will be transmitted to the host for subsequent 
processing. 

5.6 HOST COMPUTER CONFIGURATION 

The host computer configuration (hardware and software) will be an unmodified 
operational system. Data transmitted to the host from the communications 
interface configuration will be processed and entered into the performance 
evaluation data base. Error messages/reports generated will be compared with 
System/7 test reference data for verification purposes. 

5.7 PERFORMANCE EVALUATION FILE. BASE 


The data collected and processed will be entered into the data files and will 
provide the basis for user support interface verification. Plots/reports/ 
magnetic tapes will be generated from the data and analysed for correct content/ 
format/etc. SDAS sensor test reference data will be used for reference with 


user output. 
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6.0 VERIFICATION CROSS-REFERENCE MATRIX 


A verification cross-reference matrix provides the correlation among the CDPS 
performance specification and the corresponding verification techniques and 
phases. The verification matrixes for the CDPS are shown in Table 6-1. The 
matrices, therefore, provide the base for development of test procedures to 
address all performance requirements/specification. A separate verification 
matrix is provided for each CDPS element. 

The verification matrix also indicates the test procedures and test results 
documents which correspond to the Performance Requirement. This approach 
will allow ready access to the verification data relating to each entry 
in the matrix. Visibility and traceability will be achieved and will 
aid in maintaining the complete verification history throughout the mainte- 
nance/utilization of the system. In addition, as changes are made to require- 
ments, updating of test procedures will be simplified. 



3. INSPECTION N/A NOT APPLICABLE 


REMARKS 


AW „ TAU , C APPLICABLE APPLICABLE 

ACCEPTANCE TEST TEST 

PROCEDURES DOCUMENTS 


2 . 2 . 1 - 


2 . 2 . 2 - 


2.2.3- 


2.3.1- 


2.3.2- : 

2.3.3- 


2.4-1 


2.5- 1 

2 . 6 - 1 


2.7-1 


ORIGINAL plop , 
OR POOR Qulr 1 


Table 6-1. Verification matrixes (Sheet 1 of 4). 
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ITEM (NA'.'E AND FART NO.) 

CENTRAL DATA PROCESSING 
SYSTEM SOFTV/ARt 


VERIFICATION METHOD 


V 


VERIFICATION CROSS 
REFERENCE .VATRIX 
(Input Processing) 


1. SIMILARITY 

2. ANALYSIS 


3. INSPECTION 

4. TEST 


N/A NOT APPLICABLE 


VERIFICATION PHASE 


REMARKS 


PERFORMANCE 

REQUIREMENT 


DEVELOPMENT 


3.2 

Receive Data 
from Communica- 
tion Interface 

1 

3.3 

Decommutating 
Data into Scans 

4 

3.4 

Conversion to 

Engineering 

Units 

4 

3.5 

Limit Checking 

4 

3.6 

Computed Var- 
iables 

4 

3.7 

Performance 

Evaluation 

Parameters 

4 

3.8 

Data Base Input 

4 

3.9 

History/Archive 

4 

3.10 

Reports 

4 


QUALIFICATION 

4 

4 

‘ 4 
4 


4 

4 

4 

4 


Tabla 6-1. Verification matrixes (Sheet 2 of 


ACCEPTANCE 


APPLICABLE 

TEST 

PROCEDURES 


APPLICABLE 

TEST 

DOCUMENTS 


4 


3.2-1 


4 


3.3-1 


3 


.4-1 


4 

4 

4 

4 

4 

4 


3.5- 1 

3.6- 1 

3.7- 1 

3.8- 1 

3.9- 1 

3.10- 1 
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CENTRAL DATA PROCESSING 
SYSTEM SOFTWARE 


REFERENCE MATRIX 

(rile y^ir.ter.ance) 


VERIFICATION METHOD 


1. SIMILARITY 

2. ANALYSIS 


3. INSPECTION N/A NOT APPLICABLE 

4. TEST 


PERFORMANCE 

REQUIREMENT 


VERIFICATION PHASE 


DEVELOPMENT 


QUALIFICATION 


ACCEPTANCE 


REMARKS 


APPLICABLE 

TEST 

PROCEDURES 


APPLICABLE 

TEST 

DOCUMENTS 


4.2 Automatic Update 
of Data Base 

4.3 Manual Batch 
Input to Data 
Base 

4.3 Manual Terminal 
Input to Data 
Base 

4.4 Data Base 
Maintenance 

4.5 Batch Security 

4.5 Terminal 
Security 


1-4 


1 

1.4 


1.4 


1 

1.4 


4 

4 




4.2-1 


0S-GC28-6550 


4.5-1 


hRIGINAL PAGE IS 
Bf POOR QUALITY 


Table 6-1. Verification matrixes (Sheet 3 of 4) 
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PH" L, , i IWIM . 

ITEM (NAME AND PART NO.) 

CENTRAL DATA PROCESSING 
SYSTEM SOFTWARE 

» \ ) 

VERIFICATION CROSS 

REFERENCE MATRIX 
' (User Support) 

VERIFICATION METHOD 

1. SIMILARITY 3. INSPECTION N/A NOT APPLICABLE 

2. ANALYSIS 4. TEST 


PERFORMANCE 

REQUIREMENT 


Inf ornaticn 
Retrieval 

Plot Capability 

Report Genera- 
tion 

Magnetic Tape 
Generation 

Termir.al/Batch 

Capabilities 


VERIFICATION PHASE 


DEVELOPMENT 



Table 6-1. Verification matrixes (Sheet 4 of 4). 
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7.0 DEVELOPMENT VERIFICATION PLAN 


Development verification will be performed as a part of the initial CDPS 
design activities. Analysis of the proposed designs and testing of initial 
concepts will be performed to ensure that the CDPS approach selected provides 
tha growth and flexibility to address system specifications in a cost effec- 
tive manner. 

Of prime consideration in development verification will be the utilization of 
commercially available hardware and software to satisfy CDPS requirements. 
Trade analysis, and perfo rmance testing of available capabilities against' 

CDPS System Performance Specifications will provide the bases for selection. 

Development verification will consist of detailed testing of each software 
element, under simulated input conditions, to ensure that the design satisfies 
the software requirements. These tests will be executed in a standalone 
environment and will test error paths as well as the normal processing paths. 

• 

Upon completion of development verification activities on each software ele- 
ment, detailed tests will be performed, using simulated data, to test inter- 
faces among the software elements. As a result of this interface verification 
testing, the overall CDPS design will be proven and the system will be avail- 
able for qualification verification. 

Development verification of the hardware will be performed in conjunction with 
software verification. Ability to satisfactorily perform software development 
verification will prove the hardware can satisfy the design requirements for 
each system element. 

An interactive relationship will exist among development verification and CDPS 
design/ trade studles/selectlon processes. Any deficiencies noted in the 
approach will be discussed and resolved to the satisfaction of the development 
verification personnel. The interactive relationships will be internal to 
IBM; however, the results of development verification will be discussed with 
MSFC at periodic netcings/design reviews. 


page is 
*00* quautv 
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8.0 QUALIFICATION VERIFICATION PLAN 


Upon completion of development verification, qualification verification will 
'be performed. The qualification verification activities will consist of for- 
mal tasks performed in the analyses and testing of the elements of the CD?S. 
Qualification test procedures will be followed throughout the testing phase. 

Qualification verification will be performed in a building-block concept. 

Each system function (hardware and software) will be tested as a unit, and the 
units combined in an orderly manner to achieve an overall CDPS operational 
capability. The order in which the elements will be combined and tested cur- 
ing qualification testing is as follows: 

(1) S/7 configuration and SDAS for communication and data collection 

(2) S/7 - S/370 communication to achieve data flow to S/370-1-5 

(3) Input processing software process data accumulated from S/7 

(4) Data base update capability for user support verification. 

Upon completion of qualification testing, the system will be ready to undergo 
acceptance verification. 

Test/analysis results achieved as a result of qualification testing will be 
compiled into a CDPS Qualification Report. Test procedures will also be 
contained in the report. 

8.1 QUALIFICATION TEST PROCEDURES 

Formal qualification test procedures will be generated, provided to MSFC, end 
utilized during qualification verification activities. The verification cross- 
reference matrices and the OPS Performance Specification Document will provide 
Input required to define and detail these procedures. 

During CDPS qualification testing, the procedure will be updated, as required, 
to ensure that OPS elements are thoroughly verified. This update procedure 
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will be closely controlled and documented. The test procedures will be re- 
viewed with MSFC prior to utilization in testing. The procedures will also be 
Included in the Qualification Report for delivery to MSFC. 

Program Trouble and Corrective Action Reports will be generated for each prob- 
lem encountered. A sample of the form to be completed for discrepancy report- 
ing is shown in Figure 4 • Discrepancy reports must be Investigated and 
resolved prior to completion of qualification verification. Reports on status 
of discrepancies will be included in the qualification report. 

8.2 S/7-SDAS CONFIGURATION CUALI? ICATICM VERIFICATION TESTING 

The qualification verification for the S/7-SDAS configuration will ensure that 
the CDPS can perform the functions associated with telecommunications, data 
collection, and data transmission to the host computer for processing. Table 
8-1 contains the list of tests to be performed, estimated test duration time, 
and test descriptions associated with this qualification verification activity. 
These tests have been organized according to function performed by the CDPS. 

(1) Site Directory Requirements 

(2) Communication Hardware Interface •'* 

(3) S/7-SDAS Communications 
(A) Data Store 

(5) Transmit to Host 

(6) Manual SDAS Control 


PROGRAM NAME 

DATE 


INITIATOR 


TEST CASE 

PROGRAM MODULE ID 

i 

DEPT 

LOCATION 

CLOSURE 

DATE 


DESCRIPTION OF PROBLEM: 










CDPS S >FTWARE VERIFICATION PLAN 


CDPS ELEMENT: COMMUNICATION INTERFACE [x] FILE MAINTENANCE □ 

INPUT PROCESSING □ USER SUPPORT □ 

QUALIFICATION 0 

ACCEPTANCE □ 

SOFTWARE FUNCTIONAL AREA: Site Directory 

1 

j DATE: June 7, 1976 

PERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 2.2 

APPROVAL: 

l . - — .. ... 


TEST NUMBER 


DESCRIPTION (INPUT/OUTPUT/TECHNIQUE) 


2. 2. 1-1 


2. 2. 2-1 


Verify that each of the fields within the site directory is 
properly maintained during normal and abnormal site data 
collection and host transmission sessions. 


Verify that new site directory entries may be created, and 
specified fields updated. 


2. 2.3-1 


Verify that the site directory may be printed. 
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CDi’S SOFTWARE VERIFICATION FLAN 








DPS ELEMENT: COMMUNICATION INTERFACE (x] FILE MAINTENANCE □ 

INPUT PROCESSING □ USER SUPPORT □ 

QUALIFICATION □ 

ACCEPTANCE □ 

OFTWARE FUNCTIONAL AREA: Communications Hardware Interface 

DATE: June 8, 1976 

ERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 2.3 

APPROVAL: 


EST NUMBER 

2 . 3 . 1 - 1 

*1 

2 . 3 . 2 - 1 

2. 3. 3- 1 


DESCRIPTION (INPUT/OUTPUT/TECMNIQUE) 


Each of the TPMM commands shall be exercised and proper 
operation verified. 


DCI1 encoding and error detection shall be verified. 


Failures shall be Introduced to (force each hardware status 
bit to become active. Proper software response shall be 
verified. 


04 

<N 

I 

o 








CDPS JX- FT WARE VERIFICATION PLAN 


CDPS ELEMENT: 


COMMUNICATION INTERFACE [x] 
INPUT PROCESSING (“I 


SOFTWARE FUNCTIONAL AREA: SDAS Communications 

PERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 2 


FILE MAINTENANCE □ 

USER SUPPORT □ 

DATE: 


QUALIFICATION 

ACCEPTANCE 

June 8, 1976 
APPROVAL: 


TEST NUM3ER 




2.4-1 

O 


Verify communication between the SDAS and S/7 by exercising 
each of the SDAS commands and replies with and without the 
introduction of anticipated errors. 


• O 


Table 8-1. S/7 SDAS Configuration Qualification Verification Tests (Sheet 3 pf 6) 

• » * 
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COPS FTWARE VERIFICATION PLAN 

OPS ELEMENT: COMMUNICATION INTERFACE | 

INPUT PROCESSING 

H FILE MAINTENANCE 
□ USER SUPPORT 

□□ 
i 

QUALIFICATION (5) 

ACCEPTANCE □ 

0 FTWARE FUNCTIONAL AREA: Data Store 

DATE: June 8, 1976 


ERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 2 .5 


EST NUMQER DESCRIPTION (INPUT/OUTPUT/TECHNIQUE) 


APPROVAL 



EST NUMBER 
2.5-1 


The data store routine shall be tested to verify that data Is 
stored onto disk In the proper order, both with and without 
retransmissions from the SDAS. 


Table 8-1. S/7 SDAS C~ .. .'ration Qualification Verification Tests iSheet 4 of 6 






CDPS SOFTWARE VERIFICATION PLAN 

CDPS ELEMENT: COMMUNICATION INTERFACE FILE MAINTENANCE □ 

INPUT PROCESSING □ USER SUPPORT □ 

QUALIFICATION [X] 

ACCEPTANCE □ 

SOFTWARE FUNCTIONAL AREA: Data Transmission to Host 

DATE: June 8 » 1976 

PERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 2.6 

APPROVAL: 


TEST NUMBER DESCRIPTION (INPUT/OUTPUT/TECt INIQUE) 


2.6-1 Data transmission to the Host shall be verified with and 

x. without the Introduction of transmission errors. S/370 

/ CDPS software shall be; used to verify transmission format 

and accuracy. 
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cnrs CLEMENT : 


COP i SOFTWARE VERIFICATION PLAN 


COMMUNICATION INTERFACE [x] FILE MAINTENANCE Q 
INPUT PROCESSING □ USER SUPPORT □ 


QUALIFICATION 

ACCEPTANCE 


SOFTWARE FUNCTIONAL AREA: 


Manual SDAS Control 


PERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 2 . 


DATE: June 9, 1976 


APPROVAL: 


TEST NUMB! 


DESCRIPTION (INPUT/OUTPUT/TECHNIQUE) 


2.7-1 


The exercise of each of the manual commands In both normal 
and error conditions during debug of the SOAS engineering 
model hardware shall bfii the final test of this program. 


Table 8-1. S/7 SDAS Configuration Qualification Verification Tests (Sheet 6 of El 




8 . 3 HOST COMPUTER INPUT PROCSSSING QUALIFICATION TESTING 


The host computer input processing qualification testing will ensure that the 
CDPS host computer configuration satisfies all design requirements in the 
following functional areas: 


(1) S/370-145 to S/7 communication 

(2) Archiving of Raw Data 

(3) Processing of Raw Data 

(4) Computation of Analyst-Requested Variables 

(5) Computation of Performance Evaluation Parameters 

(6) Generation of Data Base Update 

(7) Summary Reports/Error Messages 

(8) Historical Data Archiving 


The test to be performed in qualification verification of these capabilities 
is given in Table 8-2. 
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CDPS .’OFTWARE VERIFICATION PLAN 


:0 PS ELEMENT: 


COMMUNICATION INTERFACE □ FILE MAINTENANCE 
INPUT PROCESSING ptl USER SUPPORT 


SOFTWARE FUNCTIONAL AREA: Receive Data from System/7 


PERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 3.2 


QUALIFICATION 

ACCEPTANCE 


DATE: June 9, 1976 


APPROVAL: 



UL 


DESCRIPTION (INPUT/OUTPUT/TECUNIQU 



3.2-1 


Receipt of data transmitted from the System/7 Communica- 
tion Interface shall be verified with and without trans- 
mission errors and retransmissions. The output data basi 
shall be tested with the file maintenance system. 






CDPS SOFTWARE VERIFICATION PLAN 


C?S ELEMENT: 


COMMUNICATION INTERFACE □ FILE MAINTENANCE 
INPUT PROCESSING Qfl USER SUPPORT 


OFTWARE FUNCTIONAL AREA: 


Raw Data Dcconunutatlon 


’ERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 3.3 


QUALIFICATION 

ACCEPTANCE 


DATE: June 9, 1976 


APPROVAL 


CST NUMBER 


DESCRIPTION (INPUT/OUTPUT/TECIiNlQUEl 


V 2 - 


Raw data deconunutation and scan time computation shall be 
verified with valid input data and with data containing 
BCH errors in each portion of a record. 


Table 8-2.’ Host Computer Input Processing Qualification Tests (Sheet 2 of 91 






CDI'S SOFTWARE VERIFICATION FLAN 


CUPS ELEMENT: 


COMMUNICATION INTERFACE □ FILE MAINTENANCE 
INPUT PROCESSING fx] USER SUPPORT 


USER SUPPORT 


QUALIFICATION 

ACCEPTANCE 


SOFTln/ARE FUNCTIONAL AREA: Conversion to Engineering Units 


PERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 


DATE: 


TEST NUMBER 


DESCRIPTION (INPUT/OUTPUT/TECIINIQUE1 




_ 3.4-1 


Verify that scan variables can be extracted and properly 
converted to engineering units through the use of the 
supported conversion techniques. 


*14 


i] 
• « 


IJ 

I’ 

II 


Table 8-2. Host Computer Input Processing Qualification Tests (Sheet 3 of 9) 





COPS SOFTWARE VERIFICATION PLAN 


>PS ELEMENT: 


COMMUNICATION INTERFACE □ FILE MAINTENANCE □ 

INPUT PROCESSING (•/] USER SUPPORT [j 


FTU'ARE FUNCTIONAL AREA: 


Limit Checking 


1RFORMANCE SPECIFICATION DOCUMENT REFERENCE: 


QUALIFICATION 

ACCEPTANCE 


DATE: . June 9, 1976 


APPROVAL: 


ST NUMDEn 


DESCRI PTION (IN PUT/OUTPUT/TECHNIQU E 


El 


Variables within limits, out of limits, and changing too 
rapidly, and stuck shall be tested with and without BCH 


errors. 


Table 8-2. Host Computer Input Processing Qualification Tests (Sheet 4 of 9) 





• COPS : OFTWARE VERIFICATION PLAN 


CDPS ELEMENT: COMMUNICATION INTERFACE □ FILE MAINTENANCE □ 

INPUT PROCESSING [x] USER SUPPORT □ 

QUALIFICATION [jQ 

ACCEPTANCE □ 

SOFTWARE FUNCTIONAL AREA: Computed Variables 

DATE: June 9, 1976 

PERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 3.6 

APPROVAL: 


TEST MUMPER DESCRIPTION UNPUT/OUTPUT/TECHNIQUEI 


3.6-1 


Computed variables shall be tested with representative 
algorithms using both valid and Invalid Input variables. 



Table 8-2. Host Computer Input Processing Qualification Tests (Sheet 5 of S) 






COPS SOFTWARE VERIFICATION PLAN 


•DPS ELEMENT: 


COMMUNICATION INTERFACE □ FILE MAINTENANCE □ 


INPUT PROCESSING PH USER SUPPORT 


OFTWARE FUNCTIONAL AREA: Performance Evaluation Parameters 


PERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 3. 


QUALIFICATION 

0 

ACCEPTANCE 

□ 


DATE: June 9, 1976 





The computation of performance evaluation parameters shall 
be tested using both valid and invalid input variables. 


O O 

i| 


Table 8-2. Host Computer Input Processing Qualification Tests (Sheet 6 of 9). 










CDPJ OFTWARE VERIFICATION PLAN 


:UPS ELEMENT: COMMUNICATION INTERFACE □ FILE MAINTENANCE □ 

INPUT PROCESSING [x] USER SUPPORT □ 

QUALIFICATION [*] 

ACCEPTANCE □ 

SOFTWARE FUNCTIONAL AREA: Data Base Input 

DATE: June 9, 1976 

PERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 3>8 

APPROVAL: 


TEST NUMBER DESCRIPTION (INPUT/OUTPUT/TECIINIQUE) 


■'"V 8-1 The merge of the latest detail data with earlier detail 

_/ data shall be verified. The hourly and daily summary 

data shall be computed using both normal and abnormal 
(missing) detail data. 

•• 






COPS SOFTWARE VERIFICATION PLAN 


SDPS ELEMENT: COMMUNICATION INTERFACE □ FILE MAINTENANCE □ 

INPUT PROCESSING [x] USER SUPPORT □ 

— : 

QUALIFICATION 0 

ACCEPTANCE □ 

SOFTWARE FUNCTIONAL AREA: History /Archive Tapes 

DATE: June 9, 1976 

PERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 3.9 

APPROVAL: 


TEST NUMBER 


DESCRIPTION (INPUT/OUTPUT/TECHNIQUE) 


3.9-1 

n 


The creation of the history and archive tapes shall be 
verified with at least 30 days data from at least 2 sites. 


r\ 


o O 

i! 



I 


Table 8-2. 




Host Computer Input Processing Qualification Tests (She^t 8 of. 9) 













CDPS i OFT WARE VERIFICATION PLAN 

:LrrS ELEMENT: COMMUNICATION INTERFACE Q FILE MAINTENANCE □ 

INPUT PROCESSING [£J USER SUPPORT Q 

QUALIFICATION [x] 

ACCEPTANCE □ 

»OF TWARE FUNCTIONAL AREA: Summary Reports 

DATE: June 9, 1976 

PERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 3.10 

APPROVAL: 


TEST MUMPER 


DESCRIPTION (INPUT/OUTPUT/TEC11NIQUE) 


J.10-1 


All reports shall be verified for readability and accuracy. 
Error messages shall be verified as erroneous data is intro- 
duced in other CDPS Input Proceseing Verification tests. 


sO 

2 


Table R-2. Host Computer Input Processing Qualification Tests (Sheet 9 of 9) 




8.4 FILE MAINTENANCE QUALIFICATION TESTING 


The CDPS file maintenance capabilities utilize an existing data base manage- 
nent system which has been proven on other activities. For this reason, 
qualification testing will consist of a functional test under maximum input 
conditions to ensure that the capability satisfies the design requirements. 
Test plans for qualification testing of the file maintenance capability are 
shown In Table 8-3. 

Functional capabilities to be tested are: 

(1) Automatic Update of Data Base 

(2) Manual Input to the Data Base 

(3) Data Base Maintenance, Access, and Update 

(4) Data Base Security 
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COPr. SOFTWARE VERIFICATION PLAN 


COPS ELEMENT: 


QUALIFICATION 


COMMUNICATION INTERFACE □ FILE MAINTENANCE QQ 

INPUT PROCESSING 0 USER SUPPORT □ 


. AREA: Input Processing/Filc Maintenance Inter facJ DATE: June 7, 1976 


ACCEPTANCE 


SOFTWARE FUNCTIONAL AREA: Input Processing/F 


PERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 


APPROVAL: 


TEST NUMBER 


DESCRIPTION (INPUT/OUTPUT/TECHNIQUE 



4.2-1 


Input processing shall process test data for 2 sites. 
File maintenance shall use the processed data to update 
the data base. 


Table 8-3. File Maintenance Qualification Tests* (Sheet 1 of 2) 




Cf PS SOFTWARE VERIFICATION PLAN 



COPS ELEMENT: COMMUNICATION INTERFACE 

INPUT PROCESSING 

□ 

□ 

FILE MAINTENANCE 
USER SUPPORT 

ED 

□ 

QUALIFICATION 0 

ACCEPTANCE □ 

SOFTWARE FUNCTIONAL AREA: File Maintenance Terminal Security 

DATE 

• June 7. 1976 

J 



Table 8-3. File Maintenance Qualification Tests (Sheet 2 of 2), 







8.5 USER SUPPORT QUALIFICATION’ VERIFICATION 


The user support qualification verification will ensure that the CDPS satis- 
fies the requirements associated with support of data base users. These 
verification tests will address the following areas: 

(1) Information Retrieval for Report Generation 

(2) Plot Capability 

(3) Daily, Monthly, Annual Reports 

(4) Magnetic Tape Generation 

(5) Terminal/Batch Capabilities 


Test plans for each of the above functional areas are shown in Table 8-4. 


CDPP. SOFTWARE VERIFICATION PLAN 


T>PS ELEMENT: COMMUNICATION INTERFACE □ FILE MAINTENANCE □ 

INPUT PROCESSING □ USER SUPPORT 0 

QUALIFICATION 0 

ACCEPTANCE □ 

JOFTWARE FUNCTIONAL AREA: Uscr Support 

DATE: June 7 » !976 

1 

PERFORMANCE SPECIFICATION DOCUMENT REFERENCE: 

APPROVAL: 


♦W-WMPEB 

.2-1 


DESCRIPTION (INPUT/OUTPUT/TECHNIQUE) 


Varied representative queries shall be made of the data 
base In both batch and terminal modes. 


✓ 


.3-1 


Representative quantities In the detail and summary data 
base shall be plotted and verified. 


i.4-1 

#.5-1 


All scheduled reports shall be generated and clarity and 
accuracy verified. 


Magnetic tapes shall be created with the Information and 
format necessary to feed Into the MSFC data base. 





8.6 OVERALL CD?S QUALIFICATION VERIFICATION TESTING 


Upon completion of qualification verification of each of the CDPS elements, 
overall end-to-end tests will be performed on the system. The test configura- 
tion will be as discussed In Section 5 of this report, and the SDAS Input will 
be simulated to provide reference Input data. These data will provide the 
following capabilities: 

(1) Nominal (No Error) Conditions 

(2) Off-Nominal (Error) Conditions 

(3) Variable Formats (14, 30, 46.) 

Through use of these reference data, system tests can be performed which will 
provide the basis for entering acceptance testing. 



w vj 

9.0 ACCEPTANCE VERIFICATION PLAN 

Upon completion of qualification verification, the CDPS will enter the accep- 
tance verification phase. This phase will exercise the CDPS in a normal 
operational environment and will provide the capability for testing of opera- 
tional procedures. The testing configuration will be as shown in Section 5 of 
this plan, and test data will consist of nominal reference data. Successful 
completion of acceptance verification will provide an operational CDPS. 

The prototype SDAS will be called via IBM tie-lines and data collected by the 
communication interface configuration. This data will, in turn, be trans- 
mitted to the host computer, processed, stored in the data base, and user 
support functions performed. Output will be provided to analysts to ensure 
proper content and format. 

9.1 ACCEPTANCE VERIFICATION PROCEDURES 


CDPS Acceptance Test Procedures shall be developed and used and will provide 
the test/analysis environment for demonstrating the overall capability of the 
CDPS in an operational environment. These procedures will be developed based 
on results of qualification verification and on system performance specifica- 
tions. Final approval of the procedures will be the result of IBM/MSFC reviews. 
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10.0 CDPS MAINTENANCE VILIFICATION APPROACH 


After the CDPS has beer, declared operational, each requirement change which 
results in codification to the systen will be evaluated for reverification 
purposes. Those changes which do not impact CDPS inter-elenent interfaces 
will undergo development and qualification verification; whereas, those result- 
ing in interface codifications will undergo all verification phases to ensure 
overall syscea continuity. Test procedures and test results will be retained 
for all maintenance verification activities. 
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